From owner-freebsd-fs Wed Aug 2 14:11:51 2000 Delivered-To: freebsd-fs@freebsd.org Received: from mail-relay.eunet.no (mail-relay.eunet.no [193.71.71.242]) by hub.freebsd.org (Postfix) with ESMTP id E0FF537B681 for ; Wed, 2 Aug 2000 14:11:42 -0700 (PDT) (envelope-from mbendiks@eunet.no) Received: from login-1.eunet.no (login-1.eunet.no [193.75.110.2]) by mail-relay.eunet.no (8.9.3/8.9.3/GN) with ESMTP id XAA85549; Wed, 2 Aug 2000 23:11:37 +0200 (CEST) (envelope-from mbendiks@eunet.no) Received: from localhost (mbendiks@localhost) by login-1.eunet.no (8.9.3/8.8.8) with ESMTP id XAA34940; Wed, 2 Aug 2000 23:11:37 +0200 (CEST) (envelope-from mbendiks@eunet.no) X-Authentication-Warning: login-1.eunet.no: mbendiks owned process doing -bs Date: Wed, 2 Aug 2000 23:11:37 +0200 (CEST) From: Marius Bendiksen To: Zhihui Zhang Cc: Steve Carlson , freebsd-fs@FreeBSD.ORG Subject: Re: FFS performance for large directories? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > you want. Other solutions exist, such as B*-Tree or Hash table. They will > speed up directories look up time. On a side note, as to B-trees or such, I think this could be done as a hack to UFS, but I'm not very intrigued by the prospect of looking into it, nor the idea of hacking it up even further. > Having said this, you can try to put all directory file into the > memory. This is the idea of matt's VMIO directory. You can definitely > find discussions on this in the mailing list archive. This will improve efficiency for situations where you reuse names or at least access stuff in a somewhat non-random manner. You may not want to use this in cases where the expected lifetime of a cache entry is low. It does not, of course, help the seek issue. Striping your raid array correctly to keep the disks from tending to be bound to eachother would probably alleviate some of the problem, but not much, I think. > A third thing is that FFS performs poor accessing /usr/ports. This has Actually, it performs poorly on any complex directory hierarchy, especially when traversed depth-first. > something to do with how FFS layout directory inode (not file inode). The It (IIRC) tries to spread the directory inodes evenly across the cylinder groups, while trying to keep the file inodes in the same cylinder group as the directory inode. Marius To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message