On Fri, Mar 24, 2000 at 09:23:57AM -0500, Jake Luck wrote:
> http://www.scriptics.com/people/john.ousterhout/seltzer.html

Note that our LFS is not quite the same as the one in 4.4 which Seltzer
describes.  Presently, it will be much more different (in some ways more
like the original Sprite LFS).

> Remember that the LFS's overhead is mainly with it's segment cleaning
> mechanism. As a result, LFS requires a great deal of free space(50%+) on
> the partition in order for it to operate efficiently. In fact, the ehanced
> FFS rivals LFS anyday regardless of the fullness of disk.

I assume you haven't actually _used_ LFS.  By effectively making all
filesystem I/O asynchronous, it provides a massive performance boost that
even newfangled tricks like 'soft updates' can't match.  Try untarring a
NetBSD source tree on an LFS and on a 'soft updates' FFS and I think you'll
see what I mean.  LFS also lacks most of the grotty ancient code that FFS
has for unravelling disks' physical geometries, which is a big win since
that code actually *costs* you performance on most drives, particularly the
parts that do things like constrain how many blocks your file can have in
the same (tiny, because of blocksize limitations) cylinder group and force
files out of the CG's their directories are in.

For any workload where the temporal locality of reference assumption holds
true, LFS also automatically provides better locality of reference than
FFS, even with all its ad-hoc tricks, can.  Of course, there are workloads
that are pathological for LFS just as there are for FFS.

I don't know where your 50% number comes from -- I can't find support for 
it in the literature.  It's true that our cleaner lacks many of the newer
techniques given in the literature for improving cleaning performance,
but it's not the case that you need as ridiculous an amount of free space
as 50% to not feel a performance impact.

Thor