| From | Sent On | Attachments |
|---|---|---|
| Steve Carlson | Jul 31, 2000 12:32 pm | |
| Zhihui Zhang | Jul 31, 2000 12:44 pm | |
| Alfred Perlstein | Jul 31, 2000 12:46 pm | |
| Terry Lambert | Jul 31, 2000 5:31 pm | |
| Kris Kennaway | Jul 31, 2000 5:45 pm | |
| Zhihui Zhang | Jul 31, 2000 5:46 pm | |
| Terry Lambert | Aug 2, 2000 1:49 pm | |
| Terry Lambert | Aug 2, 2000 1:53 pm | |
| Marius Bendiksen | Aug 2, 2000 2:05 pm | |
| Marius Bendiksen | Aug 2, 2000 2:11 pm |
| Subject: | Re: FFS performance for large directories? | |
|---|---|---|
| From: | Terry Lambert (tlam...@primenet.com) | |
| Date: | Aug 2, 2000 1:49:09 pm | |
| List: | org.freebsd.freebsd-fs | |
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 ter...@lambert.org
--- Any opinions in this posting are my own and not those of my present or previous employers.
To Unsubscribe: send mail to majo...@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message





