atom feed10 messages in org.freebsd.freebsd-fsRe: FFS performance for large directo...
FromSent OnAttachments
Steve CarlsonJul 31, 2000 12:32 pm 
Zhihui ZhangJul 31, 2000 12:44 pm 
Alfred PerlsteinJul 31, 2000 12:46 pm 
Terry LambertJul 31, 2000 5:31 pm 
Kris KennawayJul 31, 2000 5:45 pm 
Zhihui ZhangJul 31, 2000 5:46 pm 
Terry LambertAug 2, 2000 1:49 pm 
Terry LambertAug 2, 2000 1:53 pm 
Marius BendiksenAug 2, 2000 2:05 pm 
Marius BendiksenAug 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...

To Unsubscribe: send mail to majo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message