From owner-freebsd-hackers Wed Sep 2 18:56:41 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA20249 for freebsd-hackers-outgoing; Wed, 2 Sep 1998 18:56:41 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA20239 for ; Wed, 2 Sep 1998 18:56:39 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost.cdrom.com [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id SAA01561; Wed, 2 Sep 1998 18:53:31 GMT (envelope-from mike@dingo.cdrom.com) Message-Id: <199809021853.SAA01561@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Terry Lambert cc: cmascott@world.std.com (Carl Mascott), hackers@FreeBSD.ORG Subject: Re: Reading/writing /usr/ports is VERY slow In-reply-to: Your message of "Thu, 03 Sep 1998 01:08:15 GMT." <199809030108.SAA02367@usr07.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 02 Sep 1998 18:53:31 +0000 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 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