Date: 26 May 2001 16:06:59 -0400 From: Nat Lanza <magus@cs.cmu.edu> To: Andrew Reilly <areilly@bigpond.net.au> Cc: gjb@gbch.net, jandrese@mitre.org, float@firedrake.org, hackers@FreeBSD.ORG Subject: Re: technical comparison Message-ID: <khitinx4bg.fsf@dzerzhinsky.rem.cs.cmu.edu> In-Reply-To: <20010525044848.08CAC37B422@hub.freebsd.org> References: <20010525044848.08CAC37B422@hub.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Andrew Reilly <areilly@bigpond.net.au> 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; magus@cs.cmu.edu ---------------------------- all truths are half-truths http://www.cs.cmu.edu/~magus/ --------------- -- alfred north whitehead To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?khitinx4bg.fsf>