On 03/04/2011 12:30, Jonathan Tripathy wrote:
This is what state my server is currently in:
State : clean, resyncing
With mdadm 3.2.1, this will show "checking" when it is checking,
rather than "resyncing".
Interesting. So during a normal "resync", I'm guessing redundancy will
be lost?
You only need a resync when you've already lost redundancy. The only
normal resync is at array creation time, when mdadm will instantly
create the array with no redundancy and then proceed to generate the
mirror/parity information. Any other resync is only required after
something else caused a loss of redundancy e.g. a disc dying or a
system crash, or perhaps a drive threw up a bad sector. The check
process will attempt to discover any such problems.
Understood. If a problem is detected, would I have to involk a re-sync
manually (assuming that CHECK is enabled in the script)
As Doug Ledford noted in the Red Hat Bugzilla there are times when a
md RAID 1 can harmlessly end up out of sync.
Also, if the "checking" process finds an error, where will I
find it? /var/log/messages?
In the email the raid-check process sends you. Any errors found are
not reported in detail on RHEL/CentOS 5 - I think more recent
kernel/mdadm can be asked to be more verbose about the location of
errors. Requesting a repair rather than a check would get the check
process to automatically resync any stripes which had bad mirrors/parity.
How do I set up emails? Is it just the monitor deamon?
In short, it is safe to ignore a modest mismatch_cnt on RAID 1 as long
as you aren't seeing disc errors, and that is what Doug Ledford's
patch to raid-check does.
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
