From owner-freebsd-stable Mon Nov 12 11:53: 6 2001 Delivered-To: freebsd-stable@freebsd.org Received: from marvin.nildram.co.uk (marvin.nildram.co.uk [195.112.4.71]) by hub.freebsd.org (Postfix) with SMTP id 53C2137B416 for ; Mon, 12 Nov 2001 11:52:57 -0800 (PST) Received: (qmail 2881 invoked from network); 12 Nov 2001 19:52:55 -0000 Received: from muttley.gotadsl.co.uk (HELO VicNBob) (213.208.123.26) by marvin.nildram.co.uk with SMTP; 12 Nov 2001 19:52:55 -0000 Date: Mon, 12 Nov 2001 19:52:55 -0000 To: Bill Moran , Daniel Lang Cc: freebsd-stable@FreeBSD.ORG From: Matthew Whelan Subject: Re: dirpref benefit on virtual disks X-Mailer: Opera 5.11 build 904 X-Priority: 3 (Normal) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: <20011112195257.53C2137B416@hub.freebsd.org> Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 12/11/2001 18:23:52, Bill Moran wrote: >> Now I have some huge filesystems on RAID partitions. To recreate >> all their directories involves some hassle, but I would think >> about doing it. But since these are no real but virtual disks, >> spread over a set of disks in a hardware raidbox, I'm not sure, >> if I would even benefit from the better algorithm. It sounded >> a bit like designed for filesystems on a (single?) disk? > >My thought would be that, yes, it will improve performance. If >you've got a typical 3 disk, RAID-5, a read of the directory still >causes a seek on all three disks, and if there's continual seeking >across the three disks, you'll see performance degredation. If >dirpref can layout the directory info so that it's close together, >seek time is reduces, whether on 3 disks or one. There were some benchmarks posted to this list, which confirmed this. A speedup, and a very healthy one, but maybe not -quite- as much as on a single disk, ISTR maybe a 6x improvement on rm -rf /usr/ports where you'd get 10x on a single disk. Check the archives if you want better figures than my dim memory can provide. >> Also I would like to know, if there is a certain limit of free >> space, on the disk, so that the algorithm can actually use >> the better layout? The disks have some space left, in an >> absolute way, but not that much from a relative point of view >> (like 12GB left which is just 6% minfree not taken into account). > >Have a read of the original paper on FFS (which is in /usr/share/doc >if you installed docs with FreeBSD) there is an explanation of why >8% is reserved on the drive - man tunefs comments about this as well. >I would assume that the new dirpref code needs plenty of free space >to use the optimal layout policy, but I don't know if the minimal >free space is still 8% or not, and I don't know if anyone has even >tested the new dirpref code to see if that number has changed. I'd imagine a lot would depend on how fragmented your free space is, in particular, avg. fragment size vs. avg. directory size (as configured in sysctl). People have tried tar -c/rm -rf/tar -x cycles, with wildly varying improvements - from nearly no difference to nearly as good as newfs. Matthew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message