On Jan 28, 2013, at 10:37 AM, Piergiorgio Sartor [off-list ref] wrote:

On Sun, Jan 27, 2013 at 08:26:56PM +0100, Wolfgang Denk wrote:
[...]

quoted

# cat /sys/block/md0/md/mismatch_cnt
362732152


This is with mdadm v3.2.6 (mdadm-3.2.6-7.fc18.x86_64); except for the
huge values of mismatch_cnt, I see no other indications for errors on
the disk drives, RAID arrays or the file systems on top of these.

Is this some known (and hopefully harmless), issue, or must I worry
about our data?

[...]


Hi Wolfgang,

I would shamelessly suggest to try "raid6check", in order
to see if some components have problems.

The software is somehow buried into "mdadm" source code,
probably you'll need to take it from the repository.

I'm curious to see what this is and what it reveals. The thing about the count mismatch is it doesn't tell us which is incorrect: data chunk, or parity chunk. For RAID 4/5 of course this is ambiguous. But for RAID 6 it's useful to know the nature of the mismatch. Of course, there is still ambiguity, but it's not 50/50.

This is also why I'm skeptical of "repair" since it assumes the data chunks are valid in the case of a mismatch. How does this work in the case of raid 6, if the two parity chunks agree, but the data chunk mismatches? Is the data chunk still deferred to in a repair?


Chris Murphy