From owner-freebsd-hackers Thu May 24 21:49: 3 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from areilly.bpc-users.org (CPE-144-132-234-126.nsw.bigpond.net.au [144.132.234.126]) by hub.freebsd.org (Postfix) with SMTP id 08CAC37B422 for ; Thu, 24 May 2001 21:48:48 -0700 (PDT) (envelope-from andrew@areilly.bpc-users.org) Received: (qmail 55570 invoked from network); 25 May 2001 04:48:47 -0000 Received: from localhost (HELO gurney.reilly.home) (andrew@127.0.0.1) by localhost with SMTP; 25 May 2001 04:48:47 -0000 Date: Fri, 25 May 2001 14:48:46 +1000 (EST) From: Andrew Reilly Subject: Re: technical comparison To: gjb@gbch.net Cc: jandrese@mitre.org, float@firedrake.org, hackers@FreeBSD.ORG In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Message-Id: <20010525044848.08CAC37B422@hub.freebsd.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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