Re: state or future of LFS?

[Andrew Doran <ad%netbsd.org@localhost>]

On Mon, Apr 13, 2009 at 12:26:23AM +0000, David Holland wrote:

> On Fri, Apr 10, 2009 at 05:35:11PM +0000, Wouter Klouwen wrote:
>  > > So this means there is no one interested further in LFS?
>  >  
>  > No one with enough time to develop it further seems interested. :(
>  > I would, but time simply doesn't permit me.
> 
> While LFS is broken right now and is going to stay broken in 5.0,
> there's interest in getting it fixed for 6.0. This is not trivial; the
> LFS code has always had severe locking problems

`Locking problems' doesn't quite encapsulate the technical issues.
I'll be modest and leave it at that.

> and what broke it this
> time was the move to fine-grained SMP locking in the kernel.
> (vmlocking2, for those who follow things closely.)

Prior to the locking changes I was able to break it in short order. It kept
crashing ftp.netbsd.org. So it's somewhat disingenuous to claim that it was
working. Of course it was less broken, but working, no.

I spent a good deal of time hacking on both LFS and softdep while getting
VFS running fully multithreaded (the vmlocking2 stuff you mention). Softdep
and LFS together I spent roughly a month and a half on, about 10 to 16 hours
a day, intermixed with debugging other problems. No sooner than fixing one
bug I'd find another. I concluded that both were hopeless cases.

I think it's a safe bet that others ran into similar problems. Consider UBC.
In short, the shame of it is that anyone working on VFS has to maintain this
very fragile file system code, but for what payback?

If it was a first class feature and stood on its own two feet I wouldn't see
it as a problem. Working on it and fixing bugs in it would be fun. As it
stands it's not really a feature at all. It's an extravagant toy that soaks
up time and money. A problem for us because developer time and attention is
limited and NetBSD is not a rich organisation.

It extends beyond development and support too, into the realm of user
experience and reputation. If we produce some neato feature like LFS, people
are going to advocate it. When it is tried, and Murphy's law strikes, we
have created a negative impression not only of the feature but of the whole
system ("mickey mouse software").

To qualify the above, I think LFS is a neat idea and I would very much like
NetBSD to have a working LFS implementation, one that:

- demonstrates a real benefit over UFS (be it integrity or performance or ..)
- maintains integrity with write-back caching storage
- can be used in a production environment without qualms