Return to BSD News archive
Newsgroups: comp.unix.bsd.freebsd.misc Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.bhp.com.au!mel.dit.csiro.au!munnari.OZ.AU!news.ecn.uoknor.edu!qns3.qns.com!imci4!newsfeed.internetmci.com!in2.uu.net!twwells!bill From: bill@twwells.com (T. William Wells) Subject: Re: Poor performance with INN and FreeBSD. Distribution: inet Organization: None, Mt. Laurel, NJ Message-ID: <DnFBMD.M5z@twwells.com> References: <311F8C62.4BC4@pluto.njcc.com> <4gf2p0$209@fozzie.sun3.iaf.nl> <4gij7n$pmm@uriah.heep.sax.de> <4go23v$8hp@fozzie.sun3.iaf.nl> Date: Tue, 27 Feb 1996 07:32:37 GMT Lines: 39 In article <4go23v$8hp@fozzie.sun3.iaf.nl>, Geert Bosch <geert@fozzie.sun3.iaf.nl> wrote: : Since I don't know much about filesystems, my proposal might very well : be completely stupid or not applicable to FreeBSD. Since I'm not afraid : to learn, please tell me why. The key thing you're missing is that a file system has to survive various destructive influences. What this means is that the file system must have, at *all* times, a determinate state, and that state must be determinable *solely* by examining the contents of the disk. Furthermore, it is desirable that when doing file system recovery, anything that actually made it to the disk gets put where it belongs, as opposed to being deleted. It's more than desirable that during recovery, anything that is left was actually written to the disk (some versions of Unix will leave blocks of nuls at the ends of files. Not good). One thing wrong with your proposal is that it violates layering. *Only* the OS should know how the file system is put together (loosely lumping fsck and friends in with OS). One could, for example, define system calls analogous to those in VM systems, that tell the OS something about how the programs are going to use the file system -- such calls would be purely *advisory*; an OS would be free to ignore them. But the user programs should have nothing to do with the actual structure of the file system. Also, sorting is actually a very difficult operation, if you want a robust file system. Suppose that you have a two disk block directory. You read the directory in, sort it, and write it out. But, before the write of the second block, blam, your system crashes. Now, your on-disk directory has the new first block, and the old second block. You have lost everything that would have been moved out of the first block and you've duplicated everything moved out of the second block. File system recovery would get rid of the duplicates but you'll lose a whole bunch of files. This isn't to say that one can't do directories that have fast search times; it's just that naively sorting the directory is not the way to go.