On Sun, 15 Nov 2009 17:29:17 -0500 "Guy Watkins" <linux-raid@xxxxxxxxxxxxxxxx> wrote: > 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. RAID1/RAID10 are very different from RAID5/RAID6 RAID1/RAID10 can get 'mismatches' due to the particular behaviour of swap or filesystems. However this doesn't matter (the blocks that are inconsistent are of no interest to the filesystem). RAID5/RAID6 is careful not to allow any mismatches to creep in due to any particular filesystem or swap activity. This is because, as you say, those mismatches could be significant to the RAID algorithm even though they might be of no interest to the filesystem. mismatches can only occur in a RAID5/RAID6 due to a software bug in the md/raid code, or due to 'hardware errors' (including of course drive firmware errors etc). NeilBrown > > 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. -- 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
