On Thu, Mar 25, 1999 at 03:54:12PM -0500, Thor Lancelot Simon wrote:
> 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"

this is correct.  But nevertheless, people need to be warned about this.
Actually, the 

> 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.

Depends. But yes, something like this is an option.

> > * 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

ffs only moves data around when unfragmenting files, extending them, I think?
in the PGP case, you overwrite a file without changing the size, so this 
doesnt apply here.

> 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.

depending on whether he has write or only read access. But it IS a property
of the filesystem people need to be aware about.
> 
> 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.
>