Re: state or future of LFS?

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Mon, 13 Apr 2009 13:29:45 -0400
    From:        Miles Nordin <carton%Ivy.NET@localhost>
    Message-ID:  <oqtz4szcl2.fsf%castrovalva.Ivy.NET@localhost>

  | Maybe it turns out LFS really does have some significant potential
  | advantage over the latest round of extent-based copy-on-write
  | filesystems.

Maybe this might have been relevant to the message to which you were
replying, or maybe not - I don't see that it matters, as there's no
real point in "my filesystem is better than your filesystem" wars
unless they're supported by LOTS of data from LOTS of varied workloads
(and if any of those are from I/O benchmarks, those are given very little
prominence).

I didn't see that in any of this anyone is suggesting that ZFS or other
new filesystems should not be supported, so there's no real point
arguing for them - once someone does the work, I'm sure they will appear.
Further, that doesn't mean that LFS, or any other filesystem needs to
disappear - no-one suggests removing cd9660 because UDF is coming, or
the msdos (FAT) filesys because NTFS is (kind of) there - that ZFS might
appear one day is no argument at all for deleting LFS.   Nor do I believe
that's why anyone ever suggested that LFS be removed.

So, everyone please drop the fs comparisons, and if this thread is to be
continued, keep it to whether LFS should be retained or not, regardless
of what else might also exist.

On that ...

  | but whether it does or not, the other systems will not
  | stay still, so I worry even if LFS ever does work, by the time it
  | works it'll be underwhelming.

Right now, I don't think that's important.   It might have been if we
were talking about adding LFS to NetBSD, but that was done years ago,
the question now is whether to remove it, not whether to add it.

The real issue here is that LFS has been part of NetBSD for ages, and
while its reputation has never been perfect, for quite a while it was
good enough that many people seem to have decided to adopt it, and
at least some fraction of those have done so with (apparent) success.
That set doesn't include me, I was never quite brave enough to even test
drive the thing, so I have no personal stake in this discussion, but
there can be no doubt but there are people who have real LFS filesystems
in the wild.

If LFS is simply omitted (or so broken as to be totally unusable, and I
don't know from reports whether that's the case or not), then all those
people with LFS filesystems are more or less locked out of NetBSD 5
aren't they?   That, or they have to convert all their filesystems to
FFS (or something) before upgrading.

The worst scenario is for someone who upgrades then finds that their LFS
filesystems no longer work - as while upgrading is relatively painless,
downgrading systems is a nightmare.

Because of all of this, I'd submit that NetBSD 5 needs to include, at the
very least, a read-only safe LFS implementation (implemented via rump/fuse
if needed, rather than in the kernel) so that people with LFS filesystems
can at least access their data to convert it to something else after an
upgrade, if they didn't notice the requirement before the upgrade (after
all, most people read UPGRADING only after things go wrong, right???)

Better of course would be a R/W implementation, so people can continue to
work (perhaps at some performance cost, even a significant one) until they
get the opportunity to convert.

None of this has anything at all to do with whether LFS is the best filesystem
around, or even an adequate one, or whether it ever worked properly.  All
that matters is that for quite a while, NetBSD has been supporting it, and
has allowed people to build filesystems on it (that it has more or less always
been listed as experimental provides some excuse for simply dropping it, but
not really enough).

kre

ps: note that this is quite different than removing softdep - that one
affected nothing that matters inside the filesystem, so not having it
around any more means no more than (at most) needing to edit fstab to
correct, which is a whole different issue than removing LFS.