Neil Brown <neilb@xxxxxxx> writes:
> 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.
In cases where you have XOR but not copy wouldn't you XOR against a
zero filled page to copy?
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
