From owner-freebsd-performance@FreeBSD.ORG Mon May 2 14:14:56 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 C93D316A4CE for ; Mon, 2 May 2005 14:14:56 +0000 (GMT) Received: from web41212.mail.yahoo.com (web41212.mail.yahoo.com [66.218.93.45]) by mx1.FreeBSD.org (Postfix) with SMTP id 8E7CF43D2D for ; Mon, 2 May 2005 14:14:56 +0000 (GMT) (envelope-from arne_woerner@yahoo.com) Received: (qmail 90375 invoked by uid 60001); 2 May 2005 14:14:56 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=GlUbtqqXBnKIeDmVFOBf0dTY3l3cSyLTRlf3ycZJp2sITHqIhfeSQH2MEDuQd5JiX6qSqE8LAWXgtGsEjGHVXexi0RNZpYBW57gNwyJTkhvkaM1VZ92pih1kv68QUorkEGNQUKxZdwYJQI23S61O5stGMe2o/uM3KaInhzvtoOk= ; Message-ID: <20050502141456.90371.qmail@web41212.mail.yahoo.com> Received: from [83.129.199.224] by web41212.mail.yahoo.com via HTTP; Mon, 02 May 2005 07:14:56 PDT Date: Mon, 2 May 2005 07:14:56 -0700 (PDT) From: Arne "Wörner" To: Allen In-Reply-To: <6.2.1.2.2.20050502094757.037077f0@mail.rfnj.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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:14:56 -0000 --- Allen wrote: > Also you should keep in mind, there could simply be some really > goofy > controller option enabled, that forces the RAID5 to behave in a > "degraded" > state for reads -- forcing it to read up all the other disks in > the stripe > and calculate the XOR again, to make sure the data it read off > the disk > matches the checksum. It's rare, but I've seen it before, and > it will > cause exactly this sort of RAID5 performance inversion. Since > the XOR is > recalculated on every write and requires only reading up one > sector on a > different disk, options that do the above will result in read > scores > drastically lower than writes to the same array. > Isn't that compensated by the cache? I mean: We would just 1. read all the blocks, that correspond to the block, that is requested, 2. put them all into the cache 3. check the parity bits (XOR should be very fast; especially in comparison to the disc read times) 4. keep them in the cache (some kind of read ahead...) 5. send the requested block to the driver -Arne __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com