Date: Thu, 3 Sep 1998 01:08:15 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: cmascott@world.std.com (Carl Mascott) Cc: hackers@FreeBSD.ORG Subject: Re: Reading/writing /usr/ports is VERY slow Message-ID: <199809030108.SAA02367@usr07.primenet.com> In-Reply-To: <199809022252.SAA00868@europa.local> from "Carl Mascott" at Sep 2, 98 06:52:35 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> This test actually understates the performance advantage of > having the entire tree in one cylinder group because /var > is on a slower disk than is /usr. Note that this performance advantage is rather ethereal, and depends on a number of factor in the existing code which I personally do not care for, starting with the way the directory name cache precache works for a partial traversal of a directory, and the fact that the inodes referenced into the cache are not faulted-ahead so that they will be there when they are looked up. This gives the cache the false impression that it will get an ihash hit if it gets a dcache hit. In addition, there are some pessimizations in the cache code which damage coherency (but were made to work around bugs in the way the code is used). Finally, given the precache policy, on directories like the ones where you will see the performance issues you are reporting, the precache will result in hash bucket collisions that would not have occurred otherwise. In other words, the ports tree is a worst-case for the code. > I don't have a feeling for the effect of metadata updates > or the efficacy of the softupdates modifications where > write throughput is concerned. I see write throughput > of 9 KB/s in /usr/ports. Perhaps the softupdates mods > would help to get the write throughput closer to the > read throughput (i.e., improve it from abysmal to poor). This is unlikely to help. One thing to consider here is that you will most likely engage in partial track read-caching in the controller, and perhaps on the disk itself. Specifically, most modern disks record tracks in reverse sector order, and as soon as you seek to the track, they start reading (and buffering data) until they hit the sector in the track that you were actually seeking to find. > 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 > slow it down on more typical file I/O. That said, I still > have to wonder if FFS's directory placement policy can't > be improved upon. One definitely doesn't want to let a > cylinder group fill up while there is still plenty of > space in the filesystem. But it might be possible to > accomplish this without spreading new directories all > over the filesystem. In fact, directory locality is loosely assureed. I suspect that you are using a disk that either does not support tagged command queues, or supports them, but they are not enabled. Most E/IDE controllers support them (as does FreeBSD's driver), but most E/IDE devices themselves, lamentably, do not. What you may seeing is the limit of the drive to engage in elevator sorting of requests. FreeBSD used to support this, but it was diked out on the (valid) assumption that modern disk hardware would do a better job, and that implementing the code in the face of the cache unification would be prohibatively expensive. > By the way, another thing that suffers from FFS's > directory placement policy is the find command, and not > just when it is run in /usr/ports. Try running it in > /usr/src if you have a moderate amount of source > installed and just listen to your disk drive. > > I'm really curious about the directory placement policy in > vxfs (Veritas), which also has cylinder groups (called > allocation units). Does anybody happen to know what it is? The VXFS directory hierarchy management code is derived from USL's UFS (BSD FFS) implementation. There are, in fact, USL copyrights all over the source code. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. 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?199809030108.SAA02367>