UFS Subdirectory limit.

[David Malone]

[I'm not sure if Scott's comments were in relation to David Schultz's
suggestion or mine...]

> I thought that we already discussed this in the past year.  There are
> significant compatibility concerns here.  What happens if you use an
> old fsck binary on a new filesystem?  Since you haven't changed the
> magic, it has no way of knowing that nlink needs to be handled
> differently.

In the scheme I suggested, a flag in the superblock is used to
record when the new scheme is in use. I guess das's scheme would
do something similar. In my case, when you run an old fsck, the
link counts are just set to their traditional values by fsck (unless
you have a directory with too many links, in which case fsck will
do whatever it has always done in this situation).

(You also don't need to turn such a feature on by default. Both
schemes can also be read-only compatible with old systems too.)

> Also, the more important
> concern is that large directories simply don't scale in UFS.  Lookups
> are a linear operation, and while DIRHASH helps, it really doesn't scale
> well to 150k entries.

It seems to work passably well actually, not that I've benchmarked
it carefully at this size. My junkmail maildir has 164953 entries
at the moment, and is pretty much continiously appended to without
creating any problems for the machine it lives on. Dirhash doesn't
care if the entries are subdirectories or files.

If the directory entries are largely static, the name cache should
do all the work, and it is well capable of dealing with lots of
files.

We should definitely look at what sort of filesystem features we're
likely to need in the future, but I just wanted to see if we can
offer people a sloution that doesn't mean waiting for FreeBSD 6 or
7.

(164955 files now ;-)

	David.