Re: mismatch_cnt again

[Neil Brown <neilb@suse.de>]

On Mon, 16 Nov 2009 06:21:03 +0100
Goswin von Brederlow <goswin-v-b@web.de> wrote:

> Neil Brown <neilb@suse.de> writes:
> 
> > On Sun, 15 Nov 2009 17:29:17 -0500
> > "Guy Watkins" <linux-raid@watkins-home.com> 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