Andrew Reilly <[EMAIL PROTECTED]> writes:
> Where in open(1) does it specify a limit on the number of files
> permissible in a directory? The closest that it comes, that I can
> see is:
Well, read(2) doesn't tell you not to do your IO one character at a
time, but that doesn't mean it's a good idea. The point here is not
interface definitions, it's efficiency. Nobody's saying you shouldn't
be _allowed_ to put thousands and thousands of files in a directory if
you like. They're just saying that you shouldn't expect it to be fast.
Similarly, you can read data one byte at a time if you like, but you
shouldn't expect that to be fast either.
Pointing to manpages and saying you weren't warned that a particular
approach is slow is a really weak defense. Do you expect cliffs to
have little "If you drive off this cliff, you will die" warning signs
on them?
If a documented part of the API simply did not work, then you'd have a
point. Instead, what we have is a case where a method of storing files
that most people reasonably expect to be slow is in fact slow.
The folks who've pointed out the /a/a/aardvark solution are right --
directory hashing is a well-known solution to this problem. It isn't
a hack at all. No matter what method you use for storing directories,
larger directories are going to be slower to use than smaller ones,
and hashing filenames fixes that.
--nat
--
nat lanza ----------------------------------- there are no whole truths;
[EMAIL PROTECTED] ---------------------------- all truths are half-truths
http://www.cs.cmu.edu/~magus/ --------------- -- alfred north whitehead
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
