On Thu, Mar 25, 1999 at 12:48:13PM -0700, Justin T. Gibbs wrote:
> >I don't understand what you mean by "stability".  FFS with soft updates is
> >exactly like normal FFS in terms of failure recovery, it just reduces
> >synchronous write overhead while the filesystem is running.
> 
> In normal FFS, ordering restrictions are only imposed on the meta-data
> associated with a file, not its data.  With soft udpates, you are 
> also guaranteed that metadata will point to valid (filled) data blocks.
> 
> >LFS will at least let you boot your system faster,
> 
> Soft updates gives you this as well since all you need to perhaps
> add a few blocks back into the free block bitmaps and this can be
> done in the background at boot or at some regular maintenance
> interval.

And the recovery tool is where?  I don't see many people not running fsck
at boot on their FFS filesystems, and in fact the McKusick code includes
patches to fsck to detect and correct new metadata problems which can arise
specifically _because_ of the soft update code, as did the original Ganger
pseudocode.

> Because of these features, the value of LFS over FFS is marginalized.

Maybe.  When I run the McKusick soft update code, I still see an awful lot
of synchronous writes -- with LFS, I only get partial segment writes because
of update.  And despite the unnecessary memory bandwidth consumption of the
current LFS implementation, I see better write performance from LFS, both for
sustained writes to file data and for metadata operations.  The real
Achilles' heel of LFS is random-read workloads, rather analogously to FFS'
problem with random-*write* workloads -- clustering doesn't buy you much if
you have to write into cylinder groups all over the disk, one fragment at
a time.

With a data-reorganizing cleaner (even a file-coalescing cleaner is a good
start) LFS's read performance for random-read workloads can equal that of
FFS, which basically removes the only reason to not use it.  Unless you're
using a disk that's old enough to have physical geometry FFS can optimize
for -- and if you're not, all that gunk in FFS is just useless overhead.

Pointing out that soft updates *could* enable faster boot-time recovery for
FFS is like pointing out that if we had a roll-forward tool, LFS could
quickly bring you forward to the moment of the crash, much like an RDBMS
does.  Neither of the necessary tools exists; arguing about them is silly.

Not to mention that LFS's ability to write segments of uniform (and almost
arbitrary) size is tailor-made for RAID arrays.  You can run RAID 4, not
take the read-modify-write penalty on small writes, have a nice 
easy-to-expand array that doesn't require the parity rebuild that RAID 5 
does, and avoid all the other complexity and overhead of RAID 5.  This is
not surprising, because this is one of the things LFS was designed for!

(See the Sawmill paper for a good example of this)

Thor