Re: mismatch_cnt again

Bill Davidsen
2009-11-09T18:08:34Z

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