DragonFly BSD 5.4
dragonflybsd.org
dragonflybsd.org
It deserve a future not different than SSH.
On GNU/Linux I "mimic" it with a classic poor man's solution (mdraid+LUKS+LVM+nilfs2), in the past I've used zfs first on OpenSolaris (SXDE/CE/Indiana) and after even on GNU/Linux but while remain a fantastic pioneer hammer being a logged fs is far superior.
Thanks so for the hard work!
Various loads, even if not really "high" in server-like terms, very few not-clean shutdowns, mostly for testing, few fs resize (both in grow and shrink senses) + LVM resize [2], regular sync of different desktops via unison + converting in ss (snapshot) the latest cp (checkpoint) and back again after sync.
The only real problem I found is cleaner process that's extremely slow so on frequently changing fs like root, home, var etc you need to tweak config a bit [3] to make cleaner far more aggressive or require really big free space to avoid fs full from time to time due to extra cp saved...
That's really the sole problem I found. Respect of my ancient zfs-root setup is far lighter and logging is fantastic as a protection against accidental overwrite. Of course it's not as powerful as hammer and it UI is even more raw, for instance to diff a tree or a file you have to manually:
- change relevant cp to an ss
- mount the ss to an arbitrary location
- diff live vol/snap against the other mounted
A thing that limit usefulness a bit but considering that in terms of performance and overhead can be compared to a non-buggy btrfs with the overhead of xfs/jfs... It's really worth it!
[1] you only need to use a custom iso, something super-easy on NixOS, mine is here http://ix.io/1wIQ the only really important part is
boot.supportedFilesystems = [ "nilfs2" ];
boot.initrd.kernelModules = [ "crc32" "nilfs2" ];
[2] simply for grow resize first the LVM lv and after nilfs2, without dimension it grow the maximum free space available; for shrink shrink nilfs2 a bit more than the target size, resize the LVM lv to the new desired size, grow nilfs2 without dimension to occupy the entire LV free space. All operation are live, with mounted fs, it can't be resized otherwise!
[3] here http://ix.io/1wIS a really aggressive config, that on SSD essentially does not crate any noticeable overhead, on plate disk it make them spin regularly but it's just a matter of noise for desktop usage.
I remember that NILFS2 was in the middle order of magnitude in case of bugs from the presentation about filesystems fuzzing from 2016[0]. That certainly makes it more robust than BTRFS, but it's hard to compete against so much tested code like Ext4.
Time to first bug:
Ext4 2h BUG()
Xfs 1h45m Soft lockup
Gfs2 8m Double free
Ntfs 4m Soft lockup
Nilfs2 1m Page Fault
Hfs 30s Page Fault
Hfsplus 25s Page Fault
Reiserfs 25s BUG()
Ocfs2 15s BUG()
F2fs 10s BUG()
Btrfs 5s BUG()
Generally speaking I prefer experience than testing, no matter how accurate they are, I can't really tell if nilfs2 is rock solid or not due to the too little experience I have, however it's an old (so patched enough) project by a Japan telco that I think use it internally so I feel a bit of trust, the rest is covered by a good and tested backup that can't be left apart in any case and with NixOS/GuixSD even a root fs crash is not a big issue since replicate it's only a matter of copy few (possibly one) text files and let the installer do it's business... So my main point is that nilfs2 it's far lighter than zfs, it's considered safe on GNU/Linux (zfs is not) and it offer a good protection against accidental overwrite/deletion that on a desktop is important for me, even with the best and quickest backup I can imaging... I've probably remained on zfs if nilfs2 was not in kernel officially supported since years but being already there, lightweight enough it's my default choice hoping/dreaming for a different future...
The rest of panorama is really bad:
- xfs is essentially dead, like jfs
- btrfs is a shitload of bugs
- zfs can't be integrated and it's considered not production-ready on GNU/Linux
- ext* are fs from another era, without nothing of the good things of xfs/jfs
- stratis is for now more a dubious dream and not a real solution, only a way to poorly circumvent actual sorry state of storage
- bcachefs is a promise, but for now it does not offer anything relevant
- f2fs have nice performance but it's a bit buggy IME and it's even more limited than nilfs2 to a point of being unuseful...
Outside of GNU/Linux IllumOS (despite it's zombie status) and FreeBSD have a good zfs support, production ready, DragonFlyBSD have hammer, the rest is as worse as Linux world...
- stratis is kind of the traditional approach of a layered approach to filesystems instead of building the features into each filesystem. This has traditionally been a workable solution. It's reasonable to expect this to be workable going forward if not immediately.
- ZFS is 13 years old now and very much battle tested at this point. ZFS on linux goes back an entire decade.
Much of what you are running is just tested code running via a layer to provide compatibility with a different unix like OS. In fact its funny that you should mention FreeBSD considering freeBSD's will be running code based on zfs on linux.
https://lists.freebsd.org/pipermail/freebsd-fs/2018-December...
Of note
"In the past few years the vast majority of new development in ZFS has taken place in DelphixOS and zfsonlinux (ZoL). Earlier this year Delphix announced that they will be moving to ZoL"
"While working through the git history of ZoL I have also discovered that many races and locking bugs have been fixed in ZoL and never made it back to Illumos and thus FreeBSD. This state of affairs has led to a general agreement among the stakeholders that I have spoken to that it makes sense to rebase FreeBSD's ZFS on ZoL."
It seems that freebsd thinks that zfs on linux is not only production ready its better and more bug free than the illumOS version.
It's hard to imagine a universe where zfs on linux isn't considered sufficiently production ready despite having received man centuries of effort over more than a decade while hammer2 the result of what less than a man year of total effort over 4 years is. This is not to denigrate the authors efforts. DragonflyBSD and hammer2 look quite interesting.
You see a glass half empty wasteland lacking in any good options I see an embarrassment of riches current and upcoming.
XFS is maintained not "developed" anymore (despite RH/Oracle little push), as Dave Chinner announce time ago (at Vault conference few years ago, if I remember correctly) simply saying that Irix glorious time was a thing of the past and xFS codebase can't comply to modern needs so it should be considered a legacy solution...
Stratis is essentially a wrapper around actual Linux storage that try to hide it's limitation and being a RH project I expect tons of bugs and idiosyncrasy...
Zfs is battle tested on OpenSolaris, witch is unfortunately dead and IllumOS devs simply can't keep up the project, LLNL Linux port despite it's fantastic work is still not production ready on GNU/Linux despite many use it in production (including on non-ECC ram machines!)...
I tend to be pessimistic as you rightly say but I do not see any "rich present" and good upcoming future.
I see this trend few times here and it's quietly interesting: one can say "hey you state a false thing" or "I disagree because of this and that". That's help us all to understand something, expand even if a little bit our knowledge, form an opinion with stronger roots/more data etc. Otherwise it's seems to be far more like a censorship mechanism disguised by "a way to promote more interesting contents".
Think a bit about that, we miss usenet, many do not even use mailing lists at all, to few have time and resources to keep up personal websites, it's hard without a common mean of communication to reach personal websites... As a result even platforms like HN can potentially drive "the community" (in the most ample sense) to a certain direction desired not by us but by the platform holder itself or someone who abuse the platform "gamified" mechanism.
Downvotes are more useful for low quality posts that don't contribute. If something is a distraction or disruption or just plain not useful sometimes engaging would just magnify the degree of disruption or time wasting and its easier to downvote and move on.
In fact something that is worth engaging on is almost always not worthy of downvoting. In fact if you downvote the post people are less likely to read YOUR post and if it comes to pass you are correct you will have missed out on the opportunity to inform readers who now wont read the parent post you are replying to or yours.
In the end people are likely to downvote because its easier to click a little arrow than write something. I wonder if one could weigh more heavily those posts which are simultaneously downvoted and not replied to.
Gamification while have some "attraction" for many does not really guarantee that valuable contents remain available and tend to push far more extreme/non valuable contents fading into oblivion most interest stuff that might be "elitist" by nature... This, of course, while NOT counting all possible abuse in both "artificial downvote" and pushing extra contents to "censor by oblivion" unwanted contents.
Splitting platforms like StackExchange or HN vs Facebook might help and might reduce abuses but IMO it's certainly not an answer...
Source:
[1] https://forums.freebsd.org/threads/freebsd-moving-to-zfs-on-...
Having said that, I don't think rebasing to ZoL is a bad idea as long as intentions are right(FreeBSD being considered as equal, and not an after thought. No commit should be allowed if it breaks CI with FreeBSD without exceptions). Having ZFS bridging the Linux and BSD storage realms can be amazing. Also, more open source eyes on a singular OpenZFS project the better.
Here's to a better ZFS future!
A more informative post on that topic is this https://blog.fosketts.net/2017/07/10/zfs-best-filesystem-now...
XFS is the default filesystem for current RHEL [1] and SLES [2] (data partitions only in the latter case); it is as far as possible away from being "essentially dead" as a Linux filesystem can possibly be.
[1] https://access.redhat.com/articles/3129891
[2] https://www.suse.com/documentation/sles-12/singlehtml/stor_a...
If you have to choose today a classic, rock solid, battle-tested fs than xFS can be the best remaining choice on GNU/Linux. Nilfs2 is too little used and known to be "battle tested" and it's development it's extremely slow. But the rest is only experiments, bugsware, legacy or specific-purpose storage, nothing more.
[1] https://lwn.net/Articles/754504/ [2] https://lwn.net/Articles/753480/ [3] https://lwn.net/Articles/747633/
IMO it's only a way to keep up something that's needed awaiting for alternatives, do not forget how many reason, many like Andrew Morton and his "rampant layer violation" when he first meed zfs...
I've been using it for a long time and it's been rock solid. It just lacks the features of filesystems like zfs, btrfs, hammer, and bcachefs. But it's also very stable, is a tried and true filesystem, and exists right now on Linux.
So yes, it's rock solid and battle tested, certainly a safe choice respect of btrfs (buggy and not really good in production despite many do not care) or bcachefs (solid, stable, but essentially feature-less in today's implementation) but nothing more... RH and Oracle seems to push it a bit inconstantly but I still have to see any real plan...
Perhaps because HAMMER (+HAMMER2) is BSD licenced, it might have better potential as a Linux kernel module.
I also recommend trying out Bcachefs. It's developed on Debian so that's your best bet to give it a shot.
On license of course there is a problem but if we have zfs ported well... I think it can be circumvented, only I fear that in GNU/Linux land (especially -Linux part) there are too many people that do not consider at all modern needs, most of them are programmer's with no sysadmining background, they do not even understand why we desperately need new storage and "Big&Powerful" are absolutely happy because actual paleolithic storage solution means business opportunities... Remember Andrew Morton with it infamous "rampant layer violation" against zfs or NetApp that ask SUN "to unfree" zfs to avoid disrupting storage market...
IMO we have lost after Ubuntu ditch desktop the opportunity of a generic end-users GNU/Linux desktop and due to hw&sw evolution commercial-side we desperately need to innovate again as a FOSS community, DragonflyBSD is a very little substantial single-man-show project but it innovate, GNU keep innovate a bit despite a super-slow evolution and GuixSD is IMO the future of any OS, like it's "father" NixOS, the first IaC-builtin OSes in the world, but we need more, and with more manpower instead of wasting energy in evanescent crappy web-derived tech from GnomeShell extensions to Electron-based (cr)apps.
Storage in that sense is the basis since on storage we can design package managers and init systems, so in turn installers and in turn the rest of the OS. Having a modern, powerful storage, something like Plan9 propose years ago, something like Hammer, zfs, nilfs2, stratis etc are a thing that need to evolve and spread in GNU/Linux world or we can't really evolve...
It's a CoW filesystem, which should provide some inherent crash/power-fail safety that ext does not have (at least, as usually configured — and data logging has huge overhead).
On logging overhead... Well, yes and no, the logfs I tried do have overhead at garbage collection/cleaning but that overhead does not seems really important in practical terms. It demand a bit of careful design of storage layout and load prediction but nothing more than that.
I do not see practical advantage for most server usage however I see significant advantage for some server usage and certainly for desktop usage. Also potential future development is certainly interested... Imaging a package manager integrated with a logfs how effective can be only in terms of "immutable servers/IaC" applications, imaging how NixOS/GuixSD generations can easily and instantly switch, how can you deep and easily analyze datasets and systems...
Also overhead is there, a bit, today, but tomorrow can be significantly reduced if we have physical storage developed with logging in mind.
It really doesn’t get the recognition it desires. It’s has highly advanced features and performance and frankly more people should be using it.
Given the recent ZFS/FreeBSD news - I’d love more people to adopt DragonflyBSD for its Hammer2 filesysten.
I run FreeBSD ZFS on my desktop and have for years, and we're thinking of using it (for the root fs) at work. I considered the ZOL integration to be good news. We'll get better CI, and we'll share features with ZOL faster. I don't really see the downside.
I've also run ZOL for 7 years on my wife's desktops..
My understanding from the message, and from talking to the devs involved is that integration with ZOL will make FreeBSD an equal partner. FreeBSD will be included in the CI, so that ZOL changes that break FreeBSD cannot be merged. Changes originating in FreeBSD will also be merged faster to Linux, and with review from the original author to make sure they are merged correctly. Eg, it is better for everybody (except perhaps the folks left on Illumos or other Open Solaris forks).
At first came the interesting question of "what is OpenZFS"? A spec? A reference implementation that everyone branches off? How do we exchange fixes and ideas and updates?
Another topic that came up was "What should the defaults for a zpool be?" this was for portable zpools.
Please note: the above were still open questions. We're going to have a few follow up calls to understand and ideate better.
Source: I was on the call, and I'm an Illumos community member.
[0] https://docs.google.com/document/d/1w2jv2XVYFmBVvG1EGf-9A5HB...
ZoL may have more development activity behind it, but due to licencing, it will never be a first-class citizen in Linux like it is on FreeBSD/Illumos. That limitation makes the decision to turn OpenZFS (essentially, ZoL) into the upstream seem unwise.
[...] each one has a specific purpose.
OpenBSD security,
FreeBSD more desktop/server,
NetBSD “run on anything and everything”,
DragonFlyBSD scaling and performance.
First of all, when somebody reports a bug, they do not try to argue that it is not really a bug or something like that, they fix it. And then, they look through their entire code base to see if that kind of bug shows up somewhere else. It is a little sad, but even today, this attitude is not the norm. And it does not matter if that bug is remote code execution in the IP stack or a typo in one of the man pages. They fix it.
Furthermore, I like the approach to security the OpenBSD people take. As Theo de Raadt one explained in a talk, if a security feature needs to be configured before it works, people won't, and if it can be disabled, people will. So most security features on OpenBSD Just Work(tm), out of the box. Some stuff (like pf, their packet filter) obviously needs to be configured and can be disabled, but for the most part, you do not need to do anything special to enjoy the security OpenBSD offers.
Often, the OpenBSD people will do something akin to reinventing the wheel. As one comment on German IT news site once said, with any other project, you would accuse the developers of Not-Invented-Here-syndrome. But the OpenBSD people get it right.
But just to be clear, I have nothing bad to say about Mister Dillon. I hope my comment did not give you the impression I did.
I have no interest in openbsd any more. Debian is significantly better in every way except for "code correctness" and philosophical license issues which are frankly irrelevant to the end user.
I gave up and bought a mac which is a certified unix and apple pays people to actually work on the non-glamorous bits. My laptop lasts nearly all day and everything works. The UX for a laptop user is orders of magnitude better in every single way.
OpenBSD is a great idea but it's a terrible laptop OS.
They all found their purpose after the splits, not before.
> Both OpenBSD and DragonFlyBSD stem, ultimately, from personality conflicts within the developer community in FreeBSD.
> They all found their purpose after the splits, not before.
Indeed. And both are still heavily influenced by the forking BDFL figures (Theo, Dillon).
I've always been tempted to try running my website off a dragonfly instance vs managed hosting, but it's a pretty daunting switch.
I also want to say that Matthew Dillon is brilliant and a wonderful person. I played with dragonflybsd on my laptop for a while and hung out in the IRC, and he was always around and willing to help. I found a couple legitimate bugs and he had non-trivial patches up for me in like an hour.
Their networking stuff is very cool too, I can't really remember the details once, but I remember seeing an article about high performance networking that explained why you wanted to avoid the linux kernel so that you could do x,y and z yourself, and dillon explained that dragonfly kernel just does all that stuff itself.
I wish it got more use because there's so much potential there, but it's quite a chicken and the egg problem, and honestly I feel like the BSDs are kind of doomed unless they add apis that support linux containers.
I have always wondered how Matt makes a living from this given the somewhat niche positioning of Dragonfly?
I think Dillon had some sort of lock token thing? It looks like they're described here, under "LWKT Serializing Tokens:" https://www.dragonflybsd.org/docs/developer/Locking_and_Sync... . Looks somewhat easier to integrate but also some tradeoffs — proper restart when all your lock tokens get dropped seems like it might be fiddly.
https://web.archive.org/web/20170621023517/http://www.onlamp...
DragonFly belongs to the same class of operating systems
as other BSD-derived systems and Linux. It is based on the
same UNIX ideals and APIs and shares ancestor code with
other BSD operating systems. DragonFly provides an
opportunity for the BSD base to grow in an entirely
different direction from the one taken in the FreeBSD,
NetBSD, and OpenBSD series.
DragonFly includes many useful features that differentiate
it from other operating systems in the same class.https://www.dragonflybsd.org/docs/developer/Locking_and_Sync...
I don't know how well it works for them or if they've gone back to using more typical locking more recently.
Anyone else care to comment?
Think of a zfs log-structured instead of offer only snapshots. This means a complete protection against any accidental delete/overwrite since any write on disk create a new "checkpoint" and with proper file manager integration this means you can "browse history" of your's files and trees like they came from a VCS software.
There is zero filemanager integration, so only manual CLI operation with a UI a bit less comfortable than zfs, encryption have few limitations, physical volume management does not offer "built-in raids implementation" of zfs (but you can create volume on top of any supported raid config), deduplication is a bit resource intensive, replication is not clustered even if you can "mirror" (incremental mirrors included) any volume locally or on a remote machine in a way similar to zfs one...
Essentially is a zfs with a raw and a bit less intuitive UI with logfs and few nice extras.
That's true everywhere, outside specialized hardware offload.
That's not to say it is stale or anything like that; the BSDs share quite a bit of code heavily thanks to the license. And DFBSD has some novel things that FreeBSD does not have: in particular the SMP model is still distinct; they have the novel HAMMER filesystem, which no other operating system has; and they lead FreeBSD on DRM graphics drivers porting from Linux and non-uniform NUMA support (i.e., Threadripper 2990WX). There are certainly other things I am forgetting or simply don't know about; I develop FreeBSD and don't use Dragonfly myself.