On Thu, 18 Jan 2001, Greg Oster wrote:
> There are some serious consequences to doing *ANYTHING* to data on a 
> RAID set before the parity rewrite completes.  If the parity is 
> not correct for a given stripe, and you write real data to a portion 
> of that stripe, old (and *incorrect*) parity will be used to create the 
> new parity, and that new parity will also be *incorrect*.  If a component
> fails before that incorrect parity gets fixed, and that component was 
> a 'data' portion of that stripe, that data *WILL* be reconstructed 
> incorrectly.  And it won't matter if fsck had just updated that data block - 
> the reconstruction will get it *wrong*.  So even allowing fsck and the 
> parity rewrite to happen at the same time is stretching things a little...

I can see that this concern applies to flavours of RAID that use real
parity (like RAID4 and RAID5).  Does it also apply to RAID1, where the
"parity" is actually a copy of the data, and calculating the parity
doesn't require any XOR operations?

--apb (Alan Barrett)