Date: Wed, 02 Sep 1998 18:53:31 +0000 From: Mike Smith <mike@smith.net.au> To: Terry Lambert <tlambert@primenet.com> Cc: cmascott@world.std.com (Carl Mascott), hackers@FreeBSD.ORG Subject: Re: Reading/writing /usr/ports is VERY slow Message-ID: <199809021853.SAA01561@dingo.cdrom.com> In-Reply-To: Your message of "Thu, 03 Sep 1998 01:08:15 GMT." <199809030108.SAA02367@usr07.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | 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. This is only useful if the layout has clustered related directories on the disk. The current code does a good job of keeping them a long way apart. > In fact, directory locality is loosely assureed. Almost the opposite is true, especially if you don't make a common practice of deleting lots of directories. > I suspect that you are using a disk that either does not support > tagged command queues, or supports them, but they are not enabled. Multiple device openings are unuseful in this case, as you previously noted the lookup code doesn't (can't) attempt to read-ahead (it can't know where /a/b is until it has read /a, etc.) If you are performing a set of directory recursions, I/O (modulo the cache) will be performed strictly sequentially. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.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?199809021853.SAA01561>