Date: Wed, 2 Sep 1998 18:52:59 -0400 (EDT) From: Carl Mascott <cmascott@world.std.com> To: hackers@FreeBSD.ORG Subject: Re: Reading/writing /usr/ports is VERY slow Message-ID: <199809022252.SAA00872@europa.local>
next in thread | raw e-mail | index | archive | help
Luigi Rizzo wrote:
> > 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.
>
Mike Smith wrote:
> This would definitely be the case for such a relatively static layout,
> at least for the traversal case (locality of reference). I think it
> might be quite suboptimal in the case where the directories were likely
> to shrink/grow on a regular basis, simply because it would encourage
> fragmentation.
Agreed. I don't suggest abandoning cylinder groups, or allowing
a cylinder group to fill up while there's still plenty of space
in the filesystem.
Carl Mascott wrote:
> > 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.
>
Mike Smith wrote:
> One of the substantial contributors to this problem has been the
> FreeBSD policy of limiting the number of cg's by faking the disk
> layout. The intention here was to reduce the amount of space wasted in
> administrative overhead, as well as increase the likelihood of
> contiguous allocation. Unfortunately one of the less wonderful
> consequences has been the substantial increase in inter-cg distances.
For a filesystem of any given size the number of cg's is not a
factor, at least not as long as there are more than a couple of
them. As long as new directories get distributed pseudo-randomly
over the filesystem, which is what happens in /usr/ports, it
doesn't matter how many cg's the filesystem is subdivided into.
The disk arm will still be covering the same distance. However,
if a cg proximity criterion were added to the new-cg-chooser,
then the size of a cg would become a factor, although I don't
know how important a factor. For what it's worth, vxfs also
uses 32 MB cg's ("allocation units" in vxfs-speak).
Hopefully someone who knows the history of FFS development
will chime in at this point. It would be nice to know if
any other directory placement policies were ever tried and
rejected.
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?199809022252.SAA00872>