Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 02 May 2005 10:48:44 -0400
From:      asym <bsdlists@rfnj.org>
To:        Arne =?iso-8859-1?Q?=22W=F6rner=22?= <arne_woerner@yahoo.com>
Cc:        freebsd-performance@freebsd.org
Subject:   Re: Very low disk performance on 5.x
Message-ID:  <6.2.1.2.2.20050502104554.03703c10@mail.rfnj.org>
In-Reply-To: <20050502143819.49818.qmail@web41207.mail.yahoo.com>
References:  <20050502143819.49818.qmail@web41207.mail.yahoo.com>

next in thread | previous in thread | raw e-mail | index | archive | help
At 10:38 5/2/2005, Arne "W=F6rner" wrote:
>--- Allen <bsdlists@rfnj.org> wrote:
> > Scenario B, verified read enabled:
> > 1. RAID card reads up ALL blocks in the stripe (5 reads).
> > 2. RAID card pretends the block requested is on a "degraded"
> > drive, and
> > calculates it from the other 3 + the XOR stripe.
> > 3. RAID card reports the value back, or tosses some kind of
> > error.
> >
> > You can see, the cache just doesn't play a part in what I was
> > describing,
> > which is basically the array performing as though it is degraded
> > when in
> > fact it is not, to catch failures that would otherwise be
> > missed.
> >
>That would be a funny implementation. Step one could be done
>mostly from cache in case of sequential reads from a device (like
>/dev/ad0s1f or so). In this thread we always looked at sequential
>reads, as far as I recall...

It's not "funny" it's just something some people do to try to catch more=20
errors.

RAID5 will not catch transient write errors by default.  If there was say=20
noise on the bus, and so the wrong value was written to the disk after the=
=20
XOR was performed, but the right XOR data was written to the disk.

RAID5 would normally never catch such an error, unless you run it in a=20
verified mode where it always behaves as though it is degraded, which is=20
what I was describing.

Why you would, I'm not sure.  It would catch the errors I suppose, but=20
there's nothing it can do about them -- it can't know if the XOR data or=20
the actual data is corrupt.  Detection without correction is better than=20
nothing though, and if performance isn't your real goal, you can turn on=20
such features in some cards.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6.2.1.2.2.20050502104554.03703c10>