[lkml]   [2000]   [Oct]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Status of ReiserFS + Journalling
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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:39    [W:0.078 / U:6.256 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site