From owner-freebsd-performance@FreeBSD.ORG Mon May 2 14:42:46 2005 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D6A9816A4CF for ; Mon, 2 May 2005 14:42:46 +0000 (GMT) Received: from mail.rfnj.org (ns1.rfnj.org [66.180.172.156]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9C5F543D4C for ; Mon, 2 May 2005 14:42:46 +0000 (GMT) (envelope-from asym@rfnj.org) Received: from megalomaniac.rfnj.org (ool-45736df1.dyn.optonline.net [69.115.109.241]) by mail.rfnj.org (Postfix) with ESMTP id 9F2D919D; Mon, 2 May 2005 10:42:47 -0400 (EDT) Message-Id: <6.2.1.2.2.20050502104554.03703c10@mail.rfnj.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Mon, 02 May 2005 10:48:44 -0400 To: Arne =?iso-8859-1?Q?=22W=F6rner=22?= From: asym In-Reply-To: <20050502143819.49818.qmail@web41207.mail.yahoo.com> References: <20050502143819.49818.qmail@web41207.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable cc: freebsd-performance@freebsd.org Subject: Re: Very low disk performance on 5.x X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2005 14:42:46 -0000 At 10:38 5/2/2005, Arne "W=F6rner" wrote: >--- Allen 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.