Re: mismatch_cnt again

[Bill Davidsen <davidsen@tmr.com>]

Goswin von Brederlow wrote:
> Piergiorgio Sartor <piergiorgio.sartor@nexgo.de> writes:
>
>   
>> On 11/07/2009 03:58 PM, Doug Ledford wrote:
>> [...]
>>     
>>> I'm very quickly starting to become dubious of the current mismatch_cnt
>>> implementation.  I think a kernel patch is in order and I may just work
>>> on that today.  Here's the deal: a non-0 mismatch count is worthless if
>>> you don't also tell people *where* the mismatch is so they can
>>> investigate it and correct it.
>>>       
>> You're perfectly right.
>>
>> And this, again, fits in the discussion of RAID-6 error
>> check and, potentially, repair.
>>
>> Ideally the log should tell which (RAID) address has a
>> mismatch and, in case of RAID-6, if a specific device
>> could be faulty at that position.
>>     
>
> Actual in raid6 mode if one parity block is bad but the other is
> correct I would expect that to automatically repair the bad block, at
> least optionally. Same with a 3+ way mirror and one mirror being bad.
>
> In general if a block is bad and the kernel can isolate which block in
> a stripe is bad then it should repair it while checking.
>   

While I agree totally on what the kernel *should* do, AFAIK it does no 
such thing. In fact, I believe that even with a three way mirror the 
mismatch is "fixed" by picking one copy at random and writing it over 
the others, rather than voting.

I haven't looked at this in ages, but that's my memory. Like Dennis 
Miller, "I could be wrong."

-- 
Bill Davidsen <davidsen@tmr.com>
  "We can't solve today's problems by using the same thinking we
   used in creating them." - Einstein