Date: Wed, 2 Sep 1998 05:04:59 +0200 (MET DST) From: Luigi Rizzo <luigi@labinfo.iet.unipi.it> To: hackers@FreeBSD.ORG Cc: cmascott@world.std.com Subject: Re: Reading/writing /usr/ports is VERY slow (fwd) Message-ID: <Pine.BSF.3.91.980902045649.10256A-100000@labinfo.iet.unipi.it>
next in thread | raw e-mail | index | archive | help
Well, some of you might have seen this, some not, but there was a kind of interesting thread on the newsgroup about /usr/ports access speed, and the author of the message below (who is Cc:) found out that creating a partition with only one cylinder group (instead of more using the same exact disk and partition size and location) speeds up disk access for /usr/ports by a factor of 3. If i remember well the reason was, the FS code moves to a new Cylinder group to create the next directory, and this causes a lot of seeks. I am not sure where this happens, but perhaps an easy fix could be to stay in the same CG if its (CG) occupation is low enough ? Before you mention softupdates... the author also experimented with "noatime" and softupdates and the results were that using 1 CG is much faster. cheers luigi ---------- Forwarded message ---------- Date: Tue, 1 SEP 1998 01:20:50 GMT From: Carl Mascott <cmascott@world.std.com> Newgroups: comp.unix.bsd.freebsd.misc Subject: Re: Reading/writing /usr/ports is VERY slow On 31 Aug 1998 10:21:01 -0700, dillon@best.net (Matt Dillon) wrote: > :In article <EyIu6q.M21@world.std.com>, > :Carl Mascott <cmascott@world.std.com> wrote: > :>Thanks to all who confirmed that the slow filesystem throughput > :.. > :>To improve the read and write throughput from poor to > :>fair, which is the best you'll ever do with something > :>like /usr/ports, the seeks have got to be reduced a lot. > :> > :>Where to go from here? A tree like /usr/ports is really > :>atypical (2.6 small files per directory). One wouldn't > :>want to speed up FFS on /usr/ports if the result was to > > Well, everything has tradeoffs. As far as /usr/ports goes... I wouldn't > worry about /usr/ports at all. It's essentially a one-time thing, and > it doesn't make much sense to try to optimize the filesystem to handle > something that you only do a few times a year (if that, even). Softupdates > takes care of most of the problem any, so it will be a doubly-non-problem > when -current becomes -release. I'm not too worried about writing /usr/ports, which I do only when I get a new set of FBSD CD-ROMs. However, the read throughput hurts every time I back up /usr to QIC-525 tape (200 KB/s). The read throughput on /usr/ports is too slow to keep the tape streaming, even without compression, and I'd like to be able to use compression. If I could keep the tape streaming through /usr/ports it would cut the time for a compressed backup of /usr almost in half (from actual measurement). Softupdates mainly benefits write throughput because that's where most of the metadata updates occur. In my noatime read tests there were no metadata updates at all (even better than softupdates) and the read throughput was still <200 KB/s in /usr/ports. Take a look at my numbers again. The benefits of confining a directory tree to one cylinder group are about twice as great as the benefits of eliminating (not just reducing) metadata updates for the read case. As I mentioned, the directory placement policy makes "find" slow as well. That's more significant than performance in /usr/ports. I fully expect softupdates to have a significant impact on write throughput. If some 3.0 user is feeling ambitious perhaps he can measure write throughput on /usr/ports with and without softupdates. Be sure to "rm -rf /usr/ports/*" before each test, so that all of the subdirectories have to be created each time. And don't use tape as the source. Use either a different physical disk or the CD-ROM. Softupdates sounds nice. I look forward to it in -stable. But it won't make my tape stream reading /usr/ports (I think I've proven that) and it won't speed up "find" much. In short, I think that there are more long inter-group seeks on FFS than there need be, due to the directory placement policy. I consider it undesirable to spread directories out as much as possible all over the filesystem. -- Carl Mascott cmascott@world.std.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.91.980902045649.10256A-100000>