Messages in this thread |  | | From | Daniel Phillips <> | Subject | Re: Status of ReiserFS + Journalling | Date | Fri, 06 Oct 2000 10:15:20 +0200 |
| |
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 majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |