Re: mismatch_cnt again

From: Goswin von Brederlow <goswin-v-b@web.de>
To: Neil Brown <neilb@suse.de>
Cc: Guy Watkins <linux-raid@watkins-home.com>,
	'Piergiorgio Sartor' <piergiorgio.sartor@nexgo.de>,
	'Peter Rabbitson' <rabbit+list@rabbit.us>,
	'Goswin von Brederlow' <goswin-v-b@web.de>,
	'Doug Ledford' <dledford@redhat.com>,
	'Michael Evans' <mjevans1983@gmail.com>,
	'Eyal Lebedinsky' <eyal@eyal.emu.id.au>,
	'linux-raid list' <linux-raid@vger.kernel.org>
Subject: Re: mismatch_cnt again
Date: Mon, 16 Nov 2009 06:21:03 +0100	[thread overview]
Message-ID: <87tywv59kw.fsf@frosties.localdomain> (raw)
In-Reply-To: <20091116123747.29592212@notabene.brown> (Neil Brown's message of "Mon, 16 Nov 2009 12:37:47 +1100")

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?

MfG
        Goswin