From owner-freebsd-current Thu Sep 17 19:05:28 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA03430 for freebsd-current-outgoing; Thu, 17 Sep 1998 19:05:28 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA03412; Thu, 17 Sep 1998 19:05:06 -0700 (PDT) (envelope-from tlambert@usr04.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id TAA07712; Thu, 17 Sep 1998 19:04:39 -0700 (MST) Received: from usr04.primenet.com(206.165.6.204) via SMTP by smtp01.primenet.com, id smtpd007632; Thu Sep 17 19:04:30 1998 Received: (from tlambert@localhost) by usr04.primenet.com (8.8.5/8.8.5) id TAA25980; Thu, 17 Sep 1998 19:04:21 -0700 (MST) From: Terry Lambert Message-Id: <199809180204.TAA25980@usr04.primenet.com> Subject: Re: Download of FreeBSD 3.0-SNAP To: mike@smith.net.au (Mike Smith) Date: Fri, 18 Sep 1998 02:04:20 +0000 (GMT) Cc: tlambert@primenet.com, mike@smith.net.au, phk@critter.freebsd.dk, joelh@gnu.org, tom@uniserve.com, gpalmer@FreeBSD.ORG, irc@cooltime.simplenet.com, freebsd-current@FreeBSD.ORG In-Reply-To: <199809180113.SAA01834@dingo.cdrom.com> from "Mike Smith" at Sep 17, 98 06:13:57 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > 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. I meant that they do it in the right order, and not in the order Mike is using to create a slow ports tree. > 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. I disagree. I believe there is locality of reference for news groups, and thus a group (directory) having been accessed, the articles will be accessed in that locality (which *will* be in cache). It seems that what you are complaining about here is that the very first article will come up slow (but, this ignores the fact that we preferentially cache directory entries over file entries, so this will only apply when the server immediately comes up, not after it has been used for a while). In any case, news articles should probably be stored on a newsfs, such as the one currently under developement, which uses btree indices for various key fields that NNTP can ask for articles with, including header items, not just news group information. > 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. Right. Then don't do that. If you want to do something about this, commit my changes from two years ago that seperate the inode and directory allocation policies. This will let you replace the directory management code (in the current code, they are inextricable because the policy breaks are in the wrong place in the code, as I have complained and patched to no avail for several years now). I suggest using a btree, like HPFS and NTFS do. > 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. Quit exagerating "suboptimal" into "pessimal" just because you have once boundary case where the implementation is pessimal when it doesn't really have to be. 8-). I already volunteered at least part of the soloution back in 1996... 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-current" in the body of the message