Date: Fri, 25 May 2001 14:48:46 +1000 (EST) From: Andrew Reilly <areilly@bigpond.net.au> To: gjb@gbch.net Cc: jandrese@mitre.org, float@firedrake.org, hackers@FreeBSD.ORG Subject: Re: technical comparison Message-ID: <20010525044848.08CAC37B422@hub.freebsd.org> In-Reply-To: <nospam-990765146.99844@maxim.gbch.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 25 May, Greg Black wrote:
> This is just not true. For the vast majority of the systems
> that have ever been called Unix, attempting to put millions of
> files into a directory would be an utter disaster. No ifs or
> buts. It might be nice if this were different, although I see
> no good reason to support it myself, but it's generally not a
> serious possibility and so applications that depend on being
> able to do that are plain stupid. Their authors are either too
> lazy to make their use of the file system a bit more sensible or
> too stupid to know that file systems are not databases. The
> right answer is to write applications with some understanding of
> the basics of software engineering or computer science.
It's got nothing to do with the basics of software engineering or
computer science. It's got to do with interface definitions and
APIs.
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:
[ENOSPC] O_CREAT is specified, the file does not exist, and the
directory in which the entry for the new file is being
placed cannot be extended because there is no space
left on the file system containing the directory.
[ENOSPC] O_CREAT is specified, the file does not exist, and
there are no free inodes on the file system on which
the file is being created.
[EDQUOT] O_CREAT is specified, the file does not exist, and the
directory in which the entry for the new file is being
placed cannot be extended because the user's quota of
disk blocks on the file system containing the direc-
tory has been exhausted.
[EDQUOT] O_CREAT is specified, the file does not exist, and the
user's quota of inodes on the file system on which the
file is being created has been exhausted.
or perhaps:
[ENAMETOOLONG] A component of a pathname exceeded 255 characters, or
an entire path name exceeded 1023 characters.
All of which quite clearly indicate that if one wants to put all
of ones allocation of blocks or inodes into a single directory,
then one can, as long as the name and path length limits are
observed.
See: there's a system defined limit, and it's documented as such.
That's what I was getting at.
You're welcome to claim a documentation bug, and add the
appropriate caveat. It seems clear to me that Hans Reiser (and
Silicon Graphics before him) have taken the more obvious approach,
of attempting to remove the performance limitation inherent in the
existing implementation.
You can moan about tree-structured vs relational databases, but if
your problem space doesn't intrinsically map to a tree, then it
doesn't stop the tree-structring transformation that Terry
mentioned from being a gratuitious hack to work around a
performance problem with the existing implementation.
--
Andrew
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?20010525044848.08CAC37B422>