LFS vs FFS

[Terry Lambert]

"Pedro F. Giffuni" wrote:
> The NetBSD guys compared FFS and LFS here:
> http://mail-index.netbsd.org/tech-kern/2003/03/30/0001.html
> 
> "LFS beats FFS+softdep hands down, which is not
> surprising."

That was from an tar extraction shirt sleeve "benchmark";
I would expect this to be the case, since it could just
write extents.

If you notice, the wall time is the killer; this is related
to the soft updates synchronization clock latency stall.  It
can be reduced significantly by making more clock wheel entries,
or accellerating the rotation of the clock wheel under certain
load circumstances (very high load or very low load -- one of
the things I would suggest for a "soft read-only" implementation,
for example, would be, if there was a small amount of I/O, spin
it out fast, to get the system to the quiescent point faster,
and, incidently,more frequently, and for longer delta intervals).

You can't eliminate it completely; by encoding operations
ordering in the log, LFS wins out because it doesn't delay
the writes: it's just dumps the operations out in order, to
the log, not caring about anythong other than the timestamp
being monotonically increasing.

Later down, the message has "bonnie" benchmark output, which
is a mixed load benchmark, making it more representative of a
potential real-world load than the shirt-sleeve variety.

I expect that the log-thrashing which happens in LFS could
benefit from independent operation co-ordering, meaning if
it maintained a dependency list, and introduced a small
latency, rather than an update clock, it could "gather" the
writes of log entries much more effectively.


One of the comments he makes in the posting you reference
is about the "filesystem near full" case requiring exponentially
increasing time from the cleaner (which should also act as a
defragger).

The back-pressure on the FS from the cleaner needing to be
run to recover reusable extents from those out there is
probably a significant issue -- as significant as the
back-pressure on soft updates, following a very large delete.

Some of the work done to stall operations, rather than fail
them, in the presence of this back-pressure, which has been
done for soft updates is probably also applicable to LFS,
FWIW.



> I think FFS should do colocation but since there is so
> little (no) interest, perhaps it's a good time to port
> LFS:
> 
> "A preliminary conclusion is that LFS is now pretty
> stable for normal usage (although I didn't create any
> disk-nearly-full situations which make LFS' life
> hard), and then it does quite well. The write
> case is worth some investigation."
> 
> Do your own comparisons though ;).


I would like to see LFS technology revived in FreeBSD; it
was killed unfairly, IMO, through poor maintenance, though
the lack of a "cleaner" at the time was a good excuse to
not maintain the code.

-- Terry