Re: nonzero mismatch_cnt with no earlier error

[Bill Davidsen <davidsen@tmr.com>]

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@tmr.com>
  CTO TMR Associates, Inc
  Doing interesting things with small computers since 1979