Neil Brown wrote:
> Suppose, for stripe X the parity device is device 1 and we were
> updating the block on device 0 at the time of system failure.
> What had happened was that the new parity block was written out, but
> the new data block wasn't.
> Suppose further than when the system come back, device 2 has failed.
> We now cannot recover the data that was on stripe X, device 2. If we
> tried, we would xor all the blocks from working devices together and I
> hope that you can see that this would be the wrong answer. This poor,
> innocent, block, which hasn't been modified for years, has just been
> corrupted. Not good for PR.
Now that I'm getting better at thinking about this I can see that a very
simple journal will protect from this particular problem. A phase-tree
style approach would likely to the job more efficiently, once again.
Here's the ultimate simple approach: why not treat an entire stripe as
one block? That way you never get 'innocent blocks' on your stripe.
--
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
