>>>>> "dh" == David Holland <dholland-current%netbsd.org@localhost> writes:
>>>>> "tls" == Thor Lancelot Simon <tls%rek.tjls.com@localhost> writes:
tls> Journalled FFS [...] has approximately one-half the write
tls> throughput under a workload that continuously creates small
tls> files [as LFS]
ZFS never overwrites anything, so it shares at least some of the high
write performance and the fragmentation problems with LFS. but they
use ``space maps'' instead of segments and gc. I have not tried to
understand it and can't answer if it is ``log structured.'' Not
overwriting is sufficient to _be_ a log no matter what they say, but
whether it's structured like a log might be debateable.
>> Looking at the bigger picture, the NetBSD project would be
>> better served by euthanizing LFS
dh> Hardly.
How many decades more of work do you plan to trickle into it?
Filesystems have birthed and died in the amount of time LFS has been
broken.
dh> Neither ZFS nor Hammer is a log-structured file system.
If you're going to work on filesystems to try to win arguments
conducted in snarkily-worded research papers rather than to deliver
certain specific useful features already available in other
filesystems already ported to BSD, well, yeah actually, I think that's
a good idea and a good use of time. However, it might be better to
argue over a filesystem paper that isn't sixteen years old. or, at
least have a look to some of the newer less formal papers about more
complicated designs---if you don't know whether ZFS is log-structured
or not I'm guessing you haven't had more than a glance at their
documents. I think it's short of the most amazing design imagineable,
but it might have a good balance of simplicity and power.
Maybe it turns out LFS really does have some significant potential
advantage over the latest round of extent-based copy-on-write
filesystems. 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. Why not port a filesystem that already
works and already has more than one developer working on it? It might
be more fun to write something new than port someone else's spaghetti,
and it might be fun to be the only developer working on something, but
it's just not sustainable.
To me the important lesson from using ZFS is that implementation is
extremely important relative to design. After slipping their launch
by, like, a *YEAR*, it still took many more years to get the
implementation to the better-but-still-not-quite-right state it's in
now, and this is for a filesystem that already basically works!
Based on that experience it might be worth more to work even on FFS,
fixing panics and performance regressions, making it send cache-sync
commands to the drive/target, rather than pour more effort into LFS to
get it to the point where as a developer you think it's ``stable'' and
``finished,'' but sysadmins notice after a few months that mysql
performacne sucks, it loses pools like crazy over iscsi, there's no
defragmenter, you can't erase files or update mtimes on full
filesystems, certain operations use all kernel memory and start
thrashing, NFS over LFS is panic-prone, or any of the other garbage
that plagued FFS+softdep and/or FFS+wapbl for the first year of its
``finished'' existence. This is not a dig at FFS+xxx---ZFS is going
through all the same nonsense, at the same or slower development
speeds. The point is, since LFS does not even appear to work, it's
many years away from actually working. OTOH mostly-working
filesystems like ZFS, XFS, HFS+ are available now, as well as
non-working filesystems with more than 1 developer(?) and more
ambitious/log-lived scope like HAMMER (though I had the same reaction
to the design rants. the wide-eyed kool-aid ranting about the size of
certain structure fields was frightening and silly.).
As a minimum, though, I think it's worth allowing the possibility of
euthanizing LFS, of for nothing else just to get all the old LFS fans
to take their heads out of the bag and look at some ten other crazy
fancy filesystems everyone else is using that perform well, fsck fast,
and handle gigantic pools.
Attachment:
pgpWiVqiERSLG.pgp
Description: PGP signature