Date: Mon, 11 Nov 1996 18:20:50 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: msmith@atrad.adelaide.edu.au (Michael Smith) Cc: danj@3skel.com, bsdcur@shadows.aeon.net, jgreco@brasil.moneng.mei.com, freebsd-current@FreeBSD.org Subject: Re: ufs is too slow? Message-ID: <199611120120.SAA19129@phaeton.artisoft.com> In-Reply-To: <199611120007.KAA12318@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Nov 12, 96 10:37:34 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > I have seen that OpenBSD is doing something with lfs, but I > > am not sure what. It would be worth while to get lfs running > > for sure; if you ever wondered, a lot of that disk bandwith > > goes to filesystem overhead. > > Theo's words on lfs were essentially "I've never heard of it working > outside Margo's lab", in a context which I read as "lfs is bogus". I believe it works; Margo knows what the hell she's doing, unlike many people who try to pass themselves off as FS experts. There's really comparatively very little real FS research going on in the world, and I'd stack Margo up there with John Heidemann and the other Names in a heartbeat. I would also not be so quick to dismiss log structured FS's entirely; they beat journalled FS's in terms of support for implied state across multiple files. Journalled FS's can only roll those kinds of transactions back (not forward) following a failure. Further, they can't support even that without the ability to enable transaction tracking journal events, exposing them all the way to user space so the program can explicitly tell the FS about implied state. That kind of blows the reason for the implication in the first place. Journalling and log structured FS's have their places in databasing; but NetNews isn't the place. NetNews is predominantly create/read, with no intervening write accesses, followed by delite (expire). Not very impressive in terms of requirements. Given functioning soft updates, there is little reason for journalling at all... it only introduces unnecessary complexity. Depending on the boundry definitions, however, log structuring is still very useful for fast crash recovery, atomicity of multifile implied state, and record oriented manipulation of files (depending on the records, however, an LFS may be subject to high fragmentation -- for instance, variable length records, ala VMS, would be difficult to implement without needing a real defragger). The VIVA work on idempotence is especially relevant. Again, news articles are created, written only once, and not updated; there's really no reason to get more complex on a "newsfs" than doing what you can to speed up indexing, etc.. And that can be just as easily laid on *top* of *any* FS -- after all, the indices won't change significantly either, if they have correct organizing principles, since the data they refer to is invariant until expiration or creation. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611120120.SAA19129>