Neil Brown wrote:
On Monday March 5, eyal@xxxxxxxxxxxxxx wrote:
Neil Brown wrote:
[trim Q re how resync fixes data]
For raid1 we 'fix' and inconsistency by arbitrarily choosing one copy
and writing it over all other copies.
For raid5 we assume the data is correct and update the parity.
Can raid6 identify the bad block (two parity blocks could allow this
if only one block has bad data in a stripe)? If so, does it?
No, it doesn't.
I guess that maybe it could:
Rebuild each block in turn based on the xor parity, and then test
if the Q-syndrome is satisfied.
but I doubt the gain would be worth the pain.
What we really want in drives that store 520 byte sectors so that a
checksum can be passed all the way up and down through the stack
.... or something like that.
A lot of SCSI disks have that option, but I believe it's not arbitrary
bytes. In particular, the integrity check portion is only 2 bytes, 16 bits.
One option, of course, would be to store, say, 16 sectors/pages/blocks
in 17 physical sectors/pages/blocks, where the last one is a packing of
some sort of high-powered integrity checks, e.g. SHA-256, or even an ECC
block. This would hurt performance substantially, but it would be
highly useful for very high data integrity applications.
I will look at the mathematics of trying to do this with RAID-6, but I'm
99% sure RAID-6 isn't sufficient to do it, even with syndrome set
recomputation on every read.
-hpa
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
