Date: Fri, 18 Sep 1998 02:04:20 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: mike@smith.net.au (Mike Smith) 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 Subject: Re: Download of FreeBSD 3.0-SNAP Message-ID: <199809180204.TAA25980@usr04.primenet.com> In-Reply-To: <199809180113.SAA01834@dingo.cdrom.com> from "Mike Smith" at Sep 17, 98 06:13:57 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199809180204.TAA25980>