On Mon, 16 Nov 2009 06:21:03 +0100 Goswin von Brederlow <goswin-v-b@xxxxxx> wrote: > Neil Brown <neilb@xxxxxxx> writes: > > > 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 > > Does that mean raid4/5/6 always coppies the data or that it protects > it with the MMU? Always copies. Given that it has to access the data to calculate the XOR, the extra overhead of copying it is less than RAID1. Where hardware XOR support, hardware copy support is normally also available, and that is used. NeilBrown -- 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
