On Tue, 21 May 2002, Charles Shannon Hendrix wrote:

> What about losing data type problems?

Well, I don't know.  I don't see that very often, but I think it is a
symptom of LFS becoming confused due to a race of some kind, and then
writing its confusion to disk.  We won't know for sure until all the races
are gone.

> Does LFS have a likely "ready" date yet?
> More specifically, are the problems in LFS a matter of users just hunting
> down remaining problems, or is there still significant design/research
> work left?

No projected completion date: I'm working on LFS in my spare time, and I
seem to be the only one currently working on it (on ours, that is).

On the other hand, most of the work that is left before LFS "works" seems
to be (1) finding and fixing deadlock and race bugs and (2) adapting LFS
to changes merged in from other areas (softdep, ubc, etc.).  There is one
exception that I am aware of regarding cleaning of a capriciously written
filesystem; the cleaner needs to know how and when to do file coalescing.
(This is the same as the "full file system" problem.)

There are unimplemented features of LFS that shouldn't require redesign
but conceivably might: unrm(1), or an intelligent dump(8) that interacts
with the cleaner for "snapshot" dumps without impacting filesystem
performance, for example.
						Konrad Schroder
						perseant@hhhh.org