From owner-freebsd-fs Sun May 5 1:48:24 2002 Delivered-To: freebsd-fs@freebsd.org Received: from quic.net (romulus.quic.net [216.23.27.8]) by hub.freebsd.org (Postfix) with SMTP id 48B5737B404 for ; Sun, 5 May 2002 01:48:21 -0700 (PDT) Received: (qmail 19835 invoked by uid 1032); 5 May 2002 08:48:27 -0000 From: utsl@quic.net Date: Sun, 5 May 2002 04:48:27 -0400 To: Terry Lambert Cc: Bakul Shah , Scott Hess , "Vladimir B. Grebenschikov" , fs@FreeBSD.ORG Subject: Re: Filesystem Message-ID: <20020505084827.GA3688@quic.net> References: <200205040019.UAA13780@illustrious.cnchost.com> <3CD32F43.327CDA46@mindspring.com> <20020504041936.GA19646@quic.net> <3CD3FB02.3EC1DA29@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3CD3FB02.3EC1DA29@mindspring.com> User-Agent: Mutt/1.3.27i 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 On Sat, May 04, 2002 at 08:15:14AM -0700, Terry Lambert wrote: > utsl@quic.net wrote: > > [ ... linear directory search times on the majority of systems ... ] > I wasn't really trying to exhasutively list all the reasons that > it was bad to put a bunch of files in a large directory. There > are an incredibly large number of reasons for it to be bad, and > I have better things to do than spending the rest of time pointing > out impedence mismatches in algorithms. 8-). Yup. I could think of quite a few more, myself. For most people, one or two should be sufficient. > My take on an application that doesn't scale is that "fixing" the > application by changing the behaviour of the underlying system is > just propping up bad code. Bad code deserves to lose. So if > someone wrote an application like that, it's just as well that the > programmer who failed to consider scaling issues lose out to the > programmer who considered them. After all, it's very likely that > the failure to consider scaling issues is more of an "all or nothing" > thing, and that the failure to consider one means that solving it in > the OS will just expose the next one. There's really no way you > can make the OS behave perfectly for all applications. At some > point, applications programmers will have to learn how to program, > or all bets are off. Yes. Most people that supported the application I described would have liked to catch the application programmers in a dark alley. People who put 100,000 files in a single directory deserve what happens to them, IMHO. However, it is nice to have the tools to do things right. Given how common this particulary problem seems to be, I think a library might be a good idea. I may write one, I'm working on an application now that needs to be able to scale to at least 1M files. :( ---Nathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message