From owner-freebsd-performance@FreeBSD.ORG Mon May 2 12:41:10 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 1B45C16A4CF; Mon, 2 May 2005 12:41:10 +0000 (GMT) Received: from mh1.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 01CED43D31; Mon, 2 May 2005 12:41:09 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh1.centtech.com (8.13.1/8.13.1) with ESMTP id j42Cf7SS004598; Mon, 2 May 2005 07:41:08 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <42761FA7.1030500@centtech.com> Date: Mon, 02 May 2005 07:40:07 -0500 From: Eric Anderson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050325 X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-15?Q?=22Arne_=5C=22W=F6rner=5C=22=22?= References: <20050501112351.4184.qmail@web41205.mail.yahoo.com> In-Reply-To: <20050501112351.4184.qmail@web41205.mail.yahoo.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: ClamAV 0.82/861/Sat Apr 30 04:28:52 2005 on mh1.centtech.com X-Virus-Status: Clean cc: freebsd-performance@freebsd.org cc: Robert Watson 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 12:41:10 -0000 Arne W=F6rner wrote: > --- Robert Watson wrote: >=20 >>On Sat, 30 Apr 2005, Arne WXrner wrote: >> >>>3. The man page geom(4) of R5.3 says "The GEOM framework >>> provides an infrastructure in which "classes" can per- >>> form transformations on disk I/O requests on their path >>> from the upper kernel to the device drivers and back. >>> >>>Could it be, that geom slows something down (in some boxes the >>>reading=20 >>>ops are very slow; in my box the writing ops are very slow)? >> >>[...] >>against a further offset region of ad0. If they're against the >>same bits of disk, the main difference here will be the >>additional processing of the layers in the stack. A little >>bit of math is required to figure out the offset, but dd >>should be usable to figure out the incremental cost. >> >=20 > I used the following commands: > 1. dd if=3D/dev/ad0s2a bs=3D16k count=3D10000 of=3D/dev/null > 2. dd if=3D/dev/ad0 iseek=3D2100357 bs=3D16k count=3D10000 of=3D/dev/nu= ll > (I think I did the math correctly; indeed the read speed of my ad0 > varies between 45MB/sec (iseek=3D0) and 25MB/sec (in the end) with > bs=3D128k). > The results were nearly the same (both between 26MB/sec and > 28MB/sec). Maybe I should have done it in single user mode. >=20 > My other hard disc ad1 (it is newer and bigger and faster and more > furious) behaves better (but I can just try writing via the file > system (ufs+s) and a final sync): The sync just needs .24sec of > 18.28 seconds; the read and write speed is nearly the same (about > 37MB/sec+/-1MB/sec). >=20 > Is there anything else, that could help to find the reason for the > difference between ad0's speed in R4.11 and R5.3? I'll be honest here, I don't care much if the speed difference between=20 4.X and 5.X is measureable, or whatever. What I find is a little=20 telling of an issue somewhere, is that READS are slower than WRITES!=20 This is totally bogus to me - dd'ing a file to a filesystem, then=20 umounting should take longer than dd'ing from the disk to /dev/null, it=20 nearly every config I can dream up. Maybe it's the speed at which=20 /dev/null can gobble bits (seems highly unlikely!), or maybe GEOM is=20 busy doing a check or some routine to data being accessed directly from=20 the disk device instead of through a filesystem? I don't know, but it=20 is an issue, and I'm sure we'll get nailed up to a fence in some=20 benchmark somewhere if we don't fix it.. Eric --=20 ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology A lost ounce of gold may be found, a lost moment of time never. ------------------------------------------------------------------------