>>>>> "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.
Description: PGP signature