From owner-freebsd-fs Mon Jul 31 12:33:14 2000 Delivered-To: freebsd-fs@freebsd.org Received: from xo01-host074.xoom.com (xo01-host074.xoom.com [206.57.66.74]) by hub.freebsd.org (Postfix) with SMTP id EF0DA37BA82 for ; Mon, 31 Jul 2000 12:33:07 -0700 (PDT) (envelope-from stevec@nbci.com) Received: (qmail 27020 invoked from network); 31 Jul 2000 19:31:11 -0000 Received: from 209-113.snap.com (HELO ?10.12.0.136?) (206.132.209.113) by xo01-host076.xoom.com with SMTP; 31 Jul 2000 19:31:11 -0000 User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Mon, 31 Jul 2000 12:32:39 -0700 Subject: FFS performance for large directories? From: Steve Carlson To: Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org First off, my apologies in advance if this is not the type of technical question expected in this forum - I checked the charter and archives to get a feel for the theme, but still wasn't sure if this would be inappropriate. -questions was no help, either... I'm trying to figure out at what point I can expect performance issues with an FFS filesystem if I have directories with a massive number of small files or symlinks. As far as I understand it, there are a number of inodes located within a cylinder group, and the inodes for files are ideally placed in the same cylinder group as their parent directory. But if I were to have a massive number of small files or symlinks in a directory, wouldn't I run out of local inodes and thus start to see a performance issue when working in that directory? How can I determine the maximum number of files I should safely place in a directory without my performance suffering? I've been unable to find commentary on this in print or on the web - everything I've read centers only on performance issues when the disk becomes full. Thanks for any help you can offer, Steve -- Steve Carlson NBC Internet To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Mon Jul 31 12:47:14 2000 Delivered-To: freebsd-fs@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 7064437BBFB for ; Mon, 31 Jul 2000 12:47:04 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e6VJkxZ27690; Mon, 31 Jul 2000 12:46:59 -0700 (PDT) Date: Mon, 31 Jul 2000 12:46:59 -0700 From: Alfred Perlstein To: Steve Carlson Cc: freebsd-fs@FreeBSD.ORG Subject: Re: FFS performance for large directories? Message-ID: <20000731124658.G4854@fw.wintelcom.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: ; from stevec@nbci.com on Mon, Jul 31, 2000 at 12:32:39PM -0700 Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * Steve Carlson [000731 12:33] wrote: > First off, my apologies in advance if this is not the type of technical > question expected in this forum - I checked the charter and archives to get > a feel for the theme, but still wasn't sure if this would be inappropriate. > -questions was no help, either... > I'm trying to figure out at what point I can expect performance issues > with an FFS filesystem if I have directories with a massive number of small > files or symlinks. As far as I understand it, there are a number of inodes > located within a cylinder group, and the inodes for files are ideally placed > in the same cylinder group as their parent directory. But if I were to have > a massive number of small files or symlinks in a directory, wouldn't I run > out of local inodes and thus start to see a performance issue when working > in that directory? How can I determine the maximum number of files I should > safely place in a directory without my performance suffering? I've been > unable to find commentary on this in print or on the web - everything I've > read centers only on performance issues when the disk becomes full. From my experiance FFS usually starts to have problems at about 1000 to 2000 files in a directory. It's 'stable' but performance suffers. -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Mon Jul 31 12:47:47 2000 Delivered-To: freebsd-fs@freebsd.org Received: from bingnet2.cc.binghamton.edu (bingnet2.cc.binghamton.edu [128.226.1.18]) by hub.freebsd.org (Postfix) with ESMTP id 973D137BC97 for ; Mon, 31 Jul 2000 12:47:44 -0700 (PDT) (envelope-from zzhang@cs.binghamton.edu) Received: from sol.cs.binghamton.edu (sol.cs.binghamton.edu [128.226.123.100]) by bingnet2.cc.binghamton.edu (8.9.3/8.9.3) with ESMTP id PAA29487; Mon, 31 Jul 2000 15:47:34 -0400 (EDT) Date: Mon, 31 Jul 2000 15:44:57 -0400 (EDT) From: Zhihui Zhang To: Steve Carlson Cc: 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 On Mon, 31 Jul 2000, Steve Carlson wrote: > First off, my apologies in advance if this is not the type of technical > question expected in this forum - I checked the charter and archives to get > a feel for the theme, but still wasn't sure if this would be inappropriate. > -questions was no help, either... > I'm trying to figure out at what point I can expect performance issues > with an FFS filesystem if I have directories with a massive number of small > files or symlinks. As far as I understand it, there are a number of inodes > located within a cylinder group, and the inodes for files are ideally placed > in the same cylinder group as their parent directory. But if I were to have > a massive number of small files or symlinks in a directory, wouldn't I run > out of local inodes and thus start to see a performance issue when working > in that directory? How can I determine the maximum number of files I should > safely place in a directory without my performance suffering? I've been > unable to find commentary on this in print or on the web - everything I've > read centers only on performance issues when the disk becomes full. Since nobody answer your question, let me try: FFS is not very good at large directories because it has to search the directory linearly. If you have 1000 entries in a directory, then on the average, you have to search 1000/2 entries before you can get the entry you want. Other solutions exist, such as B*-Tree or Hash table. They will speed up directories look up time. 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. A third thing is that FFS performs poor accessing /usr/ports. This has something to do with how FFS layout directory inode (not file inode). The book 4.4 BSD design and implementation explains this well. If fact, read that book carefully, you can have better idea than you can get from a mailing list. Good luck! -Zhihui To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Mon Jul 31 17:34:46 2000 Delivered-To: freebsd-fs@freebsd.org Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id 2A21537B78F for ; Mon, 31 Jul 2000 17:34:38 -0700 (PDT) (envelope-from tlambert@usr07.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.9.3/8.9.3) id RAA01759; Mon, 31 Jul 2000 17:33:10 -0700 (MST) Received: from usr07.primenet.com(206.165.6.207) via SMTP by smtp04.primenet.com, id smtpdAAAwvaWPc; Mon Jul 31 17:32:25 2000 Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id RAA15725; Mon, 31 Jul 2000 17:33:38 -0700 (MST) From: Terry Lambert Message-Id: <200008010033.RAA15725@usr07.primenet.com> Subject: Re: FFS performance for large directories? To: zzhang@cs.binghamton.edu (Zhihui Zhang) Date: Tue, 1 Aug 2000 00:32:16 +0000 (GMT) Cc: stevec@nbci.com (Steve Carlson), freebsd-fs@FreeBSD.ORG In-Reply-To: from "Zhihui Zhang" at Jul 31, 2000 03:44:57 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > A third thing is that FFS performs poor accessing /usr/ports. This has > something to do with how FFS layout directory inode (not file inode). The > book 4.4 BSD design and implementation explains this well. If fact, read > that book carefully, you can have better idea than you can get from a > mailing list. Good luck! This is because the tarball is packed up in the wrong order; change the packing order (breadth-first vs. depth-first), and the "ports problem" goes away. I have done this with the -T option to tar, and it works fine, so long as you have an accurate file. This ensures that there is no cache-busting on the dearchive, which is the source of the problem. In general, your performance will vary most based on your file name length. A given directory entry block is 512b, and a given directory entry will take 8 bytes, plus however many bytes in a name, rounded to a 4 byte boundary. So for an average 8 character file name length, this works out to 32 entries per block, at 16 bytes per entry. When searching directories, the getdirentries(2) system call is used. This is normally called with a buffer capable of handling a full directory entry block worth of entries in a single system call, so with a small average file length (e.g. as with a mail queue directory), this is fairly inexpensive. NB: Mail queue directories pay heavy penalties for the MTA scanning the queue contents, much more so than the overhead of traversing the directory, so the considerations of what you _do_ with the information once you know what files are in the directory is of great importance. Normally, this is not an issue for most applications, and only specific applications have issues with lots of entries (e.g. those like MTAs that must _do_ something with the data, and those which are creating new files, since you must traverse the entire directory to create a new file, whereas doing a lookup will on average only traverse 50% of the directory -- hence negative caches are generally twice as valuable as positive caches). If you would provide more information about why you are asking the question (i.e. what is your intended application?), we could probably give you advice on how to implement it such a way as to ensure the directory depth issue does not impact you. 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-fs" in the body of the message From owner-freebsd-fs Mon Jul 31 17:45:41 2000 Delivered-To: freebsd-fs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id 042AA37BD81; Mon, 31 Jul 2000 17:45:40 -0700 (PDT) (envelope-from kris@FreeBSD.org) Received: from localhost (kris@localhost) by freefall.freebsd.org (8.9.3/8.9.2) with ESMTP id RAA14704; Mon, 31 Jul 2000 17:45:39 -0700 (PDT) (envelope-from kris@FreeBSD.org) X-Authentication-Warning: freefall.freebsd.org: kris owned process doing -bs Date: Mon, 31 Jul 2000 17:45:36 -0700 (PDT) From: Kris Kennaway To: Terry Lambert Cc: Zhihui Zhang , Steve Carlson , freebsd-fs@FreeBSD.ORG Subject: Re: FFS performance for large directories? In-Reply-To: <200008010033.RAA15725@usr07.primenet.com> 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 On Tue, 1 Aug 2000, Terry Lambert wrote: > > A third thing is that FFS performs poor accessing /usr/ports. This has > > something to do with how FFS layout directory inode (not file inode). The > > book 4.4 BSD design and implementation explains this well. If fact, read > > that book carefully, you can have better idea than you can get from a > > mailing list. Good luck! > > This is because the tarball is packed up in the wrong order; > change the packing order (breadth-first vs. depth-first), > and the "ports problem" goes away. I have done this with the > -T option to tar, and it works fine, so long as you have an > accurate file. This ensures that there is no cache-busting > on the dearchive, which is the source of the problem. Actually I benchmarked this a while back and it didn't make a significant difference. Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Mon Jul 31 17:50: 8 2000 Delivered-To: freebsd-fs@freebsd.org Received: from bingnet2.cc.binghamton.edu (bingnet2.cc.binghamton.edu [128.226.1.18]) by hub.freebsd.org (Postfix) with ESMTP id B92CB37B61D for ; Mon, 31 Jul 2000 17:50:01 -0700 (PDT) (envelope-from zzhang@cs.binghamton.edu) Received: from sol.cs.binghamton.edu (sol.cs.binghamton.edu [128.226.123.100]) by bingnet2.cc.binghamton.edu (8.9.3/8.9.3) with ESMTP id UAA00587; Mon, 31 Jul 2000 20:49:40 -0400 (EDT) Date: Mon, 31 Jul 2000 20:46:59 -0400 (EDT) From: Zhihui Zhang To: Terry Lambert Cc: Steve Carlson , freebsd-fs@FreeBSD.ORG Subject: Re: FFS performance for large directories? In-Reply-To: <200008010033.RAA15725@usr07.primenet.com> 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 > > This is because the tarball is packed up in the wrong order; > change the packing order (breadth-first vs. depth-first), > and the "ports problem" goes away. I have done this with the > -T option to tar, and it works fine, so long as you have an > accurate file. This ensures that there is no cache-busting > on the dearchive, which is the source of the problem. Good point. But what do you mean by saying "have an accurate file"? -Zhihui To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Wed Aug 2 13:50:11 2000 Delivered-To: freebsd-fs@freebsd.org Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (Postfix) with ESMTP id 72F2D37BBE2; Wed, 2 Aug 2000 13:49:56 -0700 (PDT) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.9.3/8.9.3) id NAA02528; Wed, 2 Aug 2000 13:49:30 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp01.primenet.com, id smtpdAAAklaOWe; Wed Aug 2 13:49:16 2000 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id NAA06177; Wed, 2 Aug 2000 13:49:31 -0700 (MST) From: Terry Lambert Message-Id: <200008022049.NAA06177@usr06.primenet.com> Subject: Re: FFS performance for large directories? To: kris@FreeBSD.org (Kris Kennaway) Date: Wed, 2 Aug 2000 20:49:31 +0000 (GMT) Cc: tlambert@primenet.com (Terry Lambert), zzhang@cs.binghamton.edu (Zhihui Zhang), stevec@nbci.com (Steve Carlson), freebsd-fs@FreeBSD.org In-Reply-To: from "Kris Kennaway" at Jul 31, 2000 05:45:36 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > On Tue, 1 Aug 2000, Terry Lambert wrote: > > > A third thing is that FFS performs poor accessing /usr/ports. This has > > > something to do with how FFS layout directory inode (not file inode). The > > > book 4.4 BSD design and implementation explains this well. If fact, read > > > that book carefully, you can have better idea than you can get from a > > > mailing list. Good luck! > > > > This is because the tarball is packed up in the wrong order; > > change the packing order (breadth-first vs. depth-first), > > and the "ports problem" goes away. I have done this with the > > -T option to tar, and it works fine, so long as you have an > > accurate file. This ensures that there is no cache-busting > > on the dearchive, which is the source of the problem. > > Actually I benchmarked this a while back and it didn't make a significant > difference. I have SCSI drives, so maybe that's the difference, but I was sure that only using directory components whose inodes and data were already cached would have some positive effect, and attributed the effect I saw to that, since the original problem evidenced on SCSI drives as well... 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-fs" in the body of the message From owner-freebsd-fs Wed Aug 2 13:53:47 2000 Delivered-To: freebsd-fs@freebsd.org Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id 28AD737C22D for ; Wed, 2 Aug 2000 13:53:39 -0700 (PDT) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.9.3/8.9.3) id NAA28268; Wed, 2 Aug 2000 13:52:12 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp04.primenet.com, id smtpdAAAQbaql3; Wed Aug 2 13:52:03 2000 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id NAA06373; Wed, 2 Aug 2000 13:53:27 -0700 (MST) From: Terry Lambert Message-Id: <200008022053.NAA06373@usr06.primenet.com> Subject: Re: FFS performance for large directories? To: zzhang@cs.binghamton.edu (Zhihui Zhang) Date: Wed, 2 Aug 2000 20:53:27 +0000 (GMT) Cc: tlambert@primenet.com (Terry Lambert), stevec@nbci.com (Steve Carlson), freebsd-fs@FreeBSD.ORG In-Reply-To: from "Zhihui Zhang" at Jul 31, 2000 08:46:59 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > This is because the tarball is packed up in the wrong order; > > change the packing order (breadth-first vs. depth-first), > > and the "ports problem" goes away. I have done this with the > > -T option to tar, and it works fine, so long as you have an > > accurate file. This ensures that there is no cache-busting > > on the dearchive, which is the source of the problem. > > Good point. But what do you mean by saying "have an accurate file"? If you use a naked tar without -T, then it traverses the directory, depth-first. This means that it accuractely gets all of the files that are there and packs them up. If you drive it using -T, then it depends on the contents of the list-of-files file that you tell it to use. This means that you need to make sure the list-of-files file is kept up to date, or you will miss some files and/or patches and/or new ports. It's like depending on MAKEDEV instead of devfs to keep the devices up to date: if you have stale data, then you end up with a bad result that's worse than waiting around for the cache-busting creates. 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-fs" in the body of the message From owner-freebsd-fs Wed Aug 2 14: 6: 3 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 B7C5137B5E4 for ; Wed, 2 Aug 2000 14:05:56 -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 XAA85218; Wed, 2 Aug 2000 23:05:54 +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 XAA34926; Wed, 2 Aug 2000 23:05:54 +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:05:54 +0200 (CEST) From: Marius Bendiksen To: Steve Carlson Cc: 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 > I'm trying to figure out at what point I can expect performance issues > with an FFS filesystem if I have directories with a massive number of small > files or symlinks. As far as I understand it, there are a number of inodes Small files or symlinks will usually be no problem, if they stay very small (IIRC, something like 40-60 bytes). However, directory performance may be very poor under many access patterns, due to the employment of linear scans. Also, if multiple levels are traversed depth-first, you will get very poor performance, as FFS uses a width-first layout, giving a worst-case interaction (ref. find(1) and /usr/ports). > located within a cylinder group, and the inodes for files are ideally placed > in the same cylinder group as their parent directory. But if I were to have > a massive number of small files or symlinks in a directory, wouldn't I run > out of local inodes and thus start to see a performance issue when working These parameters can be tuned by newfs. You may want to go as low as 512 bytes per inode for the layout you've described. > in that directory? How can I determine the maximum number of files I should > safely place in a directory without my performance suffering? I've been > unable to find commentary on this in print or on the web - everything I've > read centers only on performance issues when the disk becomes full. The "safe" number of files in a directory will depend on the length of the names, and how you define "suffer". UFS (which is the terminating layer of FFS et al) uses a linear directory layout. Marius To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message 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