From owner-freebsd-hackers Fri May 25 13:42:35 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp10.phx.gblx.net (smtp10.phx.gblx.net [64.211.219.59]) by hub.freebsd.org (Postfix) with ESMTP id C02DE37B422 for ; Fri, 25 May 2001 13:42:31 -0700 (PDT) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp10.phx.gblx.net (8.9.3/8.9.3) id NAA41616 for ; Fri, 25 May 2001 13:42:31 -0700 Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp10.phx.gblx.net, id smtpdaZH7aa; Fri May 25 13:42:23 2001 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id NAA13292 for hackers@freebsd.org; Fri, 25 May 2001 13:49:21 -0700 (MST) From: Terry Lambert Message-Id: <200105252049.NAA13292@usr06.primenet.com> Subject: Re: technical comparison To: hackers@freebsd.org Date: Fri, 25 May 2001 20:49:21 +0000 (GMT) X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 ] 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: [ ... ] ] 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. "UNIX, in not preventing you from doing stupid things, permits you to do clever things which other operatings systems do not permit.". I maintain that just because you are not administratively prohibited from doing stupid things, that in no way makes doing those things less stupid. ] 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. The "performance limitation"? Get your story straight: is there a limitation, or isn't there? ] 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. It is not a "performance problem with the existing implementation", it is "pilot error". There is _no_ performance problem with "the existing implementation", if you treat "postgres" as "the existing implementation"; it will do what you want, quickly and effectively, for millions of record keys. Why are you treating an FS as if it were a relational database? It is a tool intended to solve an entirely different problem set. You are bitching about your hammer not making a good screwdriver. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message