On Thu Mar 20, 2008 at 04:16:08PM +0100, Bas van Schaik wrote:
> Maybe I understand something wrong then. In an ideal situation, the
> following should hold:
> - for RAID5: all data should count up to the parity bit
> - for RAID1: all bits should be identical
>
> If the redundancy check encounters a anomaly, something should be fixed.
> If something should be fixed, clearly something went wrong somewhere in
> the past. Or can you give an example where the statements mentioned
> above don't hold and nothing is wrong?
>
My understanding is that, for RAID1 at least (and possibly for any other
mirrored setup), the data is not written to both disks simultaneously,
therefore there's a chance for the data to be modified (in memory)
between writes (or for the check to read the disks between writes).
This is usually only a temporary situation (i.e. the block is due to be
rewritten anyway) but does show up occasionally in checks, particularly
with swap partitions.
> Bottom line: I just want to know if an md check (using "echo check >
> sync_action") encountered any inconsistencies. If so, in my setup that
> would probably mean there is something wrong (bits flipping somewhere
> between md, the bus, the NIC, the network, the NIC of a storage server,
> etc.)
>
> I just don't want to be surprised by any major filesystem corruptions
> anymore!
>
For this, a simple check for a non-zero value in the
/sys/block/md{X}/md/mismatch_cnt entry will indicate an issue. Note
that the repair stage only rewrites the parity - there's no way to know
whether the actual error was in the data or parity though, so there may
still be corruption after running a repair.
Cheers,
Robin
--
___
( ' } | Robin Hill <robin@xxxxxxxxxxxxxxx> |
/ / ) | Little Jim says .... |
// !! | "He fallen in de water !!" |
Attachment:
pgp3gnFAvfZyz.pgp
Description: PGP signature
