Re: state or future of LFS?

[David Holland <dholland-current%netbsd.org@localhost>]

On Wed, Apr 15, 2009 at 08:35:54PM +0000, Andrew Doran wrote:
 > On Mon, Apr 13, 2009 at 12:35:17AM +0000, David Holland wrote:
 > > On Fri, Apr 10, 2009 at 09:06:14PM +0000, Andrew Doran wrote:
 > > > Looking at the bigger picture, the NetBSD project would be better
 > > > served by euthanizing LFS
 > > 
 > > Hardly.
 > > 
 > > Are you planning to unilaterally remove it too?
 > 
 > You're being a bit previous, aren't you?

Perhaps.

 > >  > and bringing in a similar technology with a known working
 > >  > and maintained implementation, such as ZFS or HAMMER.
 > > 
 > > Neither ZFS nor Hammer is a log-structured file system. Or at least,
 > > as far as I know ZFS isn't; Hammer's design seems to keep changing.
 > 
 > I was alluding to COW as opposed to in-place update.

That is, however, not really the critical element.

 > > I think the important structural question going forward is whether we
 > > should continue to pretend that it works to have lfs and ffs share the
 > > ufs code.
 > 
 > ufs has another consumer, ext2fs. From that standpoint it's more of an
 > aesthetic concern than anything else.

That's true, but ext2fs and ffs are structurally very similar; lfs
isn't, and to some extent at least, trying to wedge lfs into ufs is
making things messier for both ffs and ext2fs.

I'm not sure just how great that extent is. The most repellent thing I
can think of offhand is the scheme of preprocessor hacks at the top of
ufs_readwrite.c, and that clearly needs to be done some other way; a
good assessment would require digging into lfs in detail, which I have
not had time for in the last few months, any more than I've had time
for *anything* netbsd-related other than the utterly trivial.

(And since VFS-level cleanup is a much higher priority, I probably
won't be looking into lfs all that soon either.)

That said, systemic/architectural features that LFS needs in VFS, in
the buffer cache, and other fs-independent places, such as the ability
to deal with dynamic virtual-to-physical block mapping for files, need
to be kept around anyway because of e.g. nilfs and other projects.

Unhooking lfs from ufs will therefore accomplish ~everything that
removing it would. (Except for the choices other people make to spend
time on it, which is ultimately their responsibility.) So there's no
reason to remove it.

-- 
David A. Holland
dholland%netbsd.org@localhost