From owner-freebsd-current Thu Sep 17 18:14:22 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA24999 for freebsd-current-outgoing; Thu, 17 Sep 1998 18:14:22 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA24841; Thu, 17 Sep 1998 18:13:47 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost.cdrom.com [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id SAA01834; Thu, 17 Sep 1998 18:13:57 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199809180113.SAA01834@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Terry Lambert cc: mike@smith.net.au (Mike Smith), phk@critter.freebsd.dk, joelh@gnu.org, tom@uniserve.com, gpalmer@FreeBSD.ORG, irc@cooltime.simplenet.com, freebsd-current@FreeBSD.ORG Subject: Re: Download of FreeBSD 3.0-SNAP In-reply-to: Your message of "Fri, 18 Sep 1998 00:47:14 -0000." <199809180047.RAA03745@usr07.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 17 Sep 1998 18:13:57 -0700 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > That's a McCarthy "or", like "||". If the first expression ("use mtree") > > > evaluates to true, then you don't have to "force the application to > > > optimise for the filesystem it's running on". > > > > Yeah, great. Let's just "optimise", say, INN to call mtree. And CVS. > > And cp, mv and friends. > > cp -R does. Do does mv across FS's. dingo:/usr/src/bin>grep mtree cp/* mv/* Really? I don't see either of these invoking anything. > INN is, by definition, bredth-first, > since there are significantly more articale transfers than news group > creation/deletions (unless you are silly and don't follow David Lawrence, > pain that he can be...). Article creations are totally irrelevant; new file creation has no effect on the directory inode allocation policy. INN will *still* spread newly created directories suboptimally. > > Crap. The job of the filesystem is to provide optimal performance for > > typical application usage. Why do you think UFS already has > > behavioural tweaks for small files? Do you want to modify applications > > so they never create small files? > > No. I want a very deep directory tree that consists of directories > empty of anything other than directories that are empty of anything > other than directories ... that *finally* have files in them to be > created by an appropriate tool before the files are populated by > an inappropriate tool. This has nothing to do with it. As I attempted to explain while you weren't bothering to listen, it doesn't *matter* which order you create the directories in (depth first or breadth first). If you attempt to traverse the hierarchy in the same fashion as it was created, you will lose. Unless you are extremely lucky, even traversing in the opposite fashion to the order they were created will still cause you to hop all over the place, because you'll still be near to the creation order and thus will be suffering the pessimised locality of reference. *thwap* Stop being part of the problem. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message