On Thu, Mar 25, 1999 at 09:39:29PM +0100, Ignatios Souvatzis wrote:
> On Thu, Mar 25, 1999 at 03:20:39PM -0500, Thor Lancelot Simon wrote:
> > 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.
> 
> I can think of two others:
> 
> * the first stage of our two-stage bootblocks has block numbers of the 2nd one
> hardcoded into it by the installboot program. You simply can't use a data
> moving FS like LFS with that.

I see that as a weakness in our bootblocks.  They can't cope with "/boot"
being moved, either, or with a defragmentation/optimization tool for FFS
like the ones Seltzer's proposed.  Not to mention that the raw disk has to be
accessible to write them.  I've begun to think more and more recently that
a boot filesystem like Solaris uses might be The Right Way.

> * if you want to be able to _erase_ or _overwrite_ (rather than unlink or 
> replace) data, LFS is a bad idea, too. E.g., PGP users should be warned.

This can also be true of FFS -- and of course it's only true of LFS until
the cleaner runs.  The data's still not available through the filesystem;
someone with access to the raw devices can do much worse, anyway, like
modify your PGP binary.

I see the principal benefit of LFS as being for things like large external
storage arrays, source/object file trees, news spools, etc.  I don't think
the first concern applies to those, and the second is somewhat of a nonissue
because if you _only_ care about whether the filesystem overwrites the data
in the same place on the disk, you don't care enough to have real security
anyway.