Anyway - the question remains - would this be the right approach?
Hmm - I wonder what would be needed to make the resync code do this...
No, it wouldn't. In RAID5 implementations, parity isn't recalculated when you write to a RAID, It's updated. My understanding is that typical implementations are, *VERY* basically:
read the old data xor with the new data read the parity data xor with the parity data write the new data write the new parity data
Thus a RAID5 write is really two disk reads and two disk writes, which is why RAID5 is expensive for writing. Under this scheme, if the parity is bad, and you write data to "update" it, it's still bad because you haven't recalculated anything. If the parity is good, everything stays in sync.
If you were to truly recalculate parity every time you wrote to a block, it'd be something like:
write the new data read the corresponding data blocks from the other drives recalculate parity based on all blocks write the new parity data
That would be n-1 reads and 2 writes for every write, which would get expensive as your number of drives increased. It's something like this that the update=resync option in mdadm does, that is it reads every drive's data and actually recalculates the parity based on that.
Philip - 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
