From owner-freebsd-fs Fri May 3 17:19:50 2002 Delivered-To: freebsd-fs@freebsd.org Received: from illustrious.cnchost.com (illustrious.concentric.net [207.155.252.7]) by hub.freebsd.org (Postfix) with ESMTP id 77F7737B417 for ; Fri, 3 May 2002 17:19:47 -0700 (PDT) Received: from bitblocks.com (adsl-209-204-185-216.sonic.net [209.204.185.216]) by illustrious.cnchost.com id UAA13780; Fri, 3 May 2002 20:19:40 -0400 (EDT) [ConcentricHost SMTP Relay 1.14] Message-ID: <200205040019.UAA13780@illustrious.cnchost.com> To: Terry Lambert Cc: Bakul Shah , Scott Hess , "Vladimir B. Grebenschikov" , fs@FreeBSD.ORG Subject: Re: Filesystem In-reply-to: Your message of "Fri, 03 May 2002 16:52:18 PDT." <3CD322B2.FBEF3C19@mindspring.com> Date: Fri, 03 May 2002 17:19:39 -0700 From: Bakul Shah Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Terry Lambert writes: > Bakul Shah wrote: > > > In any case, it's still an incredibly bad idea to have even a tenth > > > of that man objects in a single directory, period. > > > > IMHO it is a bad idea to not have evolved directories to use > > a B-tree representation (at least when the number of entries > > exceed some threshold. Implement mechanisms and leave > > policies to the users! > > You can argue this, but then we are left with software that > will only run well on AIX or [insert pet platform here], and > runs dog slow on other platforms, because it assumes that > the underlying implementation will always be O(log2(N)) instead > of O(N) or O(N**2). > > It's a really crappy program that relies on underlying OS > specific features for its efficiencies, because as soon as it's > ported to an OS where the assumptions it makes are no longer > true, it's screwed. Unless enough systems provide this capability no one sane will use it. So yes, portability suffers. My frustration is with the 70s mindset when it comes to extending basic capabilities. Reasoning like: the disk access speed is very slow so the speed of directory access is not an issue. And since speed is not an issue a linear search is fine and dandy. Never mind that with a large buffer cache, chances are you will find dir. blocks in core and a linear search is not a great searching strategy when you have more than 10 to 20 items. And this is not the only such instance in the kernel. If you build scalable solutions people will use them. If enough Unix variants provide fast dir search, others will have to pick it up. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message