"Guy Watkins" <linux-raid@xxxxxxxxxxxxxxxx> writes:
> I have been following this issue some, and I think this could be a cause for
> silent corruption on RAID5 and RAID6. I don't think this has been
> mentioned, if so, sorry.
>
> If data blocks can be changed in memory before written to disk, even if the
> data blocks that were changed were never needed again from the disk, the
> other related blocks in the stripe are at risk. If the parity blocks are
> computed, then the 1 data block in memory is changed, then the blocks are
> written to disk, the parity would be wrong. If a disk fails and is re-added
> or replaced, the data block in that stripe will be computed using the
> changed block giving a now corrupt value. I am assuming the stripe has some
> data blocks that have needed data and at least 1 that was not needed, and
> that block that was not needed was changed before writing it to disk. And
> the disk that failed did not have the block that had been changed.
>
> I have a hard time conveying my thought in text. I hope you understand me.
>
> Thanks for reading.
In short, the block on the replaced disk will be wrong and won't be
the one that caused the mismatch. I.e. a second block gets broken.
Replace another disk ad yet another block gets wrong. and so on.
MfG
Goswin
--
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
