Justin Piszcz wrote:
On Sat, 24 Feb 2007, Michael Tokarev wrote:
Jason Rainforest wrote:
I tried doing a check, found a mismatch_cnt of 8 (7*250Gb SW RAID5,
multiple controllers on Linux 2.6.19.2, SMP x86-64 on Athlon64 X2 4200
+).
I then ordered a resync. The mismatch_cnt returned to 0 at the start of
As pointed out later it was repair, not resync.
the resync, but around the same time that it went up to 8 with the
check, it went up to 8 in the resync. After the resync, it still is
8. I
haven't ordered a check since the resync completed.
As far as I understand, repair will do the same as check does, but ALSO
will try to fix the problems found. So the number in mismatch_cnt after
a repair will indicate the amount of mismatches found _and fixed_
/mjt
That is what I thought too (I will have to wait until I get another
mismatch to verify), but FYI--
Yesterday I had 512 mismatches for my swap partition (RAID1) after I
ran the check.
I ran repair.
I catted the mismatch_cnt again, still 512.
I re-ran the check, back to 0.
AFAIK the "repair" action will give you a count of the repairs it does,
and will fail a drive if a read does not succeed after the sector is
rewritten. That's the way I read it, and the way it seems to work.
--
bill davidsen <davidsen@xxxxxxx>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
-
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
