My biggest interest in DragonFlyBSD is hammer storage, while I of course appreciate the general hard work hw support and general usage does not suite most of my needs, especially when I start using NixOS/GuixSD with the wonderful idea of having declarative/functional systems that's the future of ANY OS IMVHO but hammer by itself is fantastic.
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.
Could you expand upon poor man's solution (mdraid+LUKS+LVM+nilfs2)? I'm mainly interested in NILFS2 part. For the long time I intend to use it. I thought about /home for me and/or my father and lately just for an archive partition (a bit like Fossil from Plan 9). I heard that there is a disagreement on whether it needs fsck or not. It does not have it and theoretically does not need it. But I heard about unrecoverable errors that probably could be fixed by hypothetical fsck. I can't find it now, it was some kind of a blog post that summed up the disagreement.
Well, for now is about an year with few machines (personal desktop, home server, laptop and few friends machines) on NixOS, root included [1] issueless.
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
[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.
Your welcome and thanks for the link, I do not know it :-)
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...
- XFS is actively developed with the linux kernel.
- 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.
"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.
A small things: while I'm not much interest in "voting" and "gamification" (and they are NOT part of hacker culture) when people upvote/downvote a post WHY THE HELL they do not COMMENT to explain their reasoning?
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.
Downvote for disagree is a poor strategy. For example I didn't downvote you.
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.
IMO in today's community (too big and less and less acculturated in any sense than the past) we need personal websites that collect peoples public ideas and a discussion platform like usenet. On usenet there is a continuous stream of contents, valuable one may then end-up in some personal sites and being cited in future posts so newcomers can still discover it when needed/desired while not much valuable one slowly or quickly be forgotten in ngs history's...
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...
Agree with the sentiment on XFS. It will be interesting to see what the future ‘unifying’ file system will be for Linux given Btrfs is dead as a donut (afaik).
Your statement on ZFS is factually incorrect, I would say. iXsystems develop and support plenty of enterprise grade systems with ZFS on Linux. The OpenZFS project is alive and kicking with several platforms including FreeBSD and Linux. FreeBSD has run off the OpenSolaris upstream source for years, but has recently announced they are rebasing to ZFS on Linux [1]. This means less / no fiddling around with feature flags to share file systems between FreeBSD and Linux. Long live OpenZFS!
Can't comment on others, but ZFS. I fell in love with FreeBSD + ZFS when I set up a dedicated file server. The ease of use, feature set, integration, and reliability is just lovely. At times, I cannot believe that I'm getting all of it for free from an open source project (Ex-NetApp er, who was amazed by WAFL before touching ZFS).
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.
In the past I'd loved zfs and I still love it's physical volume management ability and it's concept of pooled storage however after years I choose to ditch it.
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.
Yep, than go looking at xFS commits history, mailing list activities, websites (sgi site dead, xfs.org abandoned)... It's "live" in the sense that's bugfixed when bug spot around but there is essentially ZERO new futures, even in 2015 one of it's lead devs say it's legacy, damn that I do not find a video of the talk...
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.
A couple minutes with a search engine finds several articles on new features such as "XFS online filesystem scrubbing and repair" [1][2], as well as plans for a substantial interface rework to implement subvolumes and snapshots [3], from this year.
So I assume that someone still want to keep it up, however if an ancient core developer, years ago (2015) already depict the project as at a dead end...
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.
If I remember correctly at a Vault Conference few years ago Dave Chinner say that xFS codebase while actively maintained should be considered legacy since it's not really possible evolve it anymore and the better way to go is a complete re-design so a new filesystem, a thing that will not happen in xFS upstream... I do not find any transcript now, but looking for it somewhere in the web surely exists :-)
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...
I tried out bcachefs in the recent past but... Well... for now it's only a classic, usable, stable fs... All the nice features are only promises in development, no snapshot, no replication, nothing is there only a stable fs that seems no different than ext...
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...
> Well... for now it's only a classic, usable, stable fs ... nothing is there only a stable fs that seems no different than ext...
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).
Sorry my not-so-good English sometimes make me express concept in a convoluted/wrong way, on my previous post s/no/not much/ (different) than ext, it's an interesting project however today is only that IMO a thing to follow, prize, support but not use regularly apart if you want to help it's developments...
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.
Sure, HAMMER(2) is licensed for portability elsewhere. The trick would be adapting Dragonfly's VFS interface (and locking!) to your target platform. It has diverged from FreeBSD in ways that make that non-trivial, and Linux's system is even more different.
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..
Sadly, FreeBSD (and Illumos) are now defacto downstreams, since a lot of the active ZFS work is now happening on Linux. That's a sad fact, but true, and sticking our heads in the sand won't change it. (and may, in fact, make it worse).
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).
During last month's openzfs call [0], one of the actions items that came up for discussion was "How do we all work together?" There are scenarios where issues on ZoL are still being investigated on Illumos. I don't know further details on this, sorry.
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.
I just wanted to add: the real challenges are figuring out what it means to have a shared code base across oppressing systems for a file system. This is not like openssh. The porting, verification and feature parity checks are unique and challenging to solve.
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.
Honestly, due to the licensing it's not exactly a first-class citizen on FreeBSD either. It's a copyleft license that doesn't pollute other source files, but it's still copyleft for ZFS itself. That is contra to the BSD license.
Integration of ZFS will always be an issue in any platform that is not licensed under Sun’s CDL license. To run ZFS, FreeBSD developers had to effectively build a kernel module that paravirtualises the OpenSolaris kernel. So there will always be integration work. The new upstream rebase should make integration much more smooth and allow for features to be released more quickly to FreeBSD than we have been able to do previously.
Are there benchmarks that show Hammer2 faster than a decently configured ZFS setup? What’s it offer that ZFS and snapshots and the like doesn’t? I’m not trying to start a flame war just curious
I keep looking at it because ZFS deduplication is unusable for me. In every instance I've tried using it, it has resulted in kernel panics likely due to out of memory. My current backup server, where I'd really like to use it, would need something like $1,500 of RAM to support dedup, if I measure it correctly (because the simulation seems to only do active blocks, not snapshots, so I don't have a good idea of actual DDT RAM required).
Dedup is indeed very memory hungry with ZFS. Likely cheaper / more cost effective to buy a bucket load of disk storage and extend your pool using raidz rather than adding ecc mem for ZFS.
Ahh yeah dedup is a ram hungry feature. I am hoping the devs find a way to fix that maybe with some novel use of data structures that make it less ram heavy. But it could be relate to the copy on write nature of ZFS and not be possible.
Just myself trying to fit the various *BSD's in my mind, I found this[0] which might be helpful:
[...] each one has a specific purpose.
OpenBSD security,
FreeBSD more desktop/server,
NetBSD “run on anything and everything”,
DragonFlyBSD scaling and performance.
OpenBSD has a reputation for security but if you ask me its killer features are ease of use, documentation (the man pages are so good), and laptop compatibility.
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.
I've run OpenBSD on my Thinkpad for two years, only plugging it in at night, and everything works (sleep, resume, good battery life). Which Thinkpad model do you have? When did you last try OpenBSD? Maybe I could help.
I had/have an X220. I try it every few years and it's always the same issues. Pre- and post- cpu scaling "fix".
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.
That's sort of reconned, though. NetBSD split from FreeBSD because the former was a bunch of Unix hackers working on Unix hardware and the latter wanted to focus on the 386 port. 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.
I'd be curious to hear more about your experience doing this. What hosting provider do you use? Most of the major ones don't seem particularly BSD-friendly.
I've always been tempted to try running my website off a dragonfly instance vs managed hosting, but it's a pretty daunting switch.
ramnode lets you do custom isos and since it is KVM they are pretty good for this. I run it on the smallest instance too with 1gb of ram and 2gb of swap.
Every time I read about DragonFly I’m never quite sure what it can do that’s different than other OSes that makes it interesting. The best I can tell it’s just that some of the subsystems are different and it’s more of an experiment for under the hood OS features.
Their filesystem is interesting but what I find impressive is they're at like a linux level of performance despite having a team of like 10 people because of the way they approached concurrency. I believe they spawned out of dillon disagreeing with freebsd's approach, and it's beautiful to me that they're competitive with linux despite not having a huge team of people polishing it.
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.
IIRC, Matt forked FreeBSD from v4 as he disagreed with the approach taken to SMP (ie multi processor support) in v5. He forked v4 and wrote his own patch set to deliver SMP support. That is a long time ago.
I haven’t run Hammer / Hammer2 so cannot comment on why it is awesome. To me my file system needs to be properly battle tested and trusting my precious personal data to a one man band feels a bit too esoteric.
I have always wondered how Matt makes a living from this given the somewhat niche positioning of Dragonfly?
Hah, I wasn't around at that time. I believe FreeBSD 5 went ahead and did the same thing most other BSDs and Linux did initially, which was the so-called "Giant" lock scheme, where only one CPU could be in the kernel at a time. The plan being to gradually break things into smaller locks. That's more or less worked (for FreeBSD and maybe NetBSD — OpenBSD still has notoriously poor kernel concurrency in 2018), but didn't yield high concurrency up front, and there are still vestigial uses of Giant in FreeBSD.
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.
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.
It may be experimental in that it's diverged significantly from FreeBSD, from which it was forked. But experimental does not mean new. Release 1.0 was in July 2004. Apparently the lead developer's experience with the Amiga OS influenced the project to some degree.
Yeah, Dillon (lead developer) forked FreeBSD 4 over (at least) a dispute in how SMP should be implemented. (FreeBSD 5 was the first release to support SMP.) DragonFlyBSD => DFBSD => Dillon's FreeBSD.
I recall back then Dillon had some unconventional ideas how to do SMP compared to the traditional approach of ever more fine-grained locking as done by FreeBSD and Linux. Is DragonFlyBSD still following this design, and if so, how well did it work out, or if not, did they revert to a more traditional approach?
Google tells me that this is a fork of FreeBSD from some years ago, and that there is some desktop support and some degree of support for laptops, especially Thinkpads from a few years ago.
I'v tried it in the past because of Hammer storage (please do not call it fs), hw support at that time was far from good and desktop usability is reasonably low (though not much lower than {Open,Net}BSD) but without counting cluster's hammer by itself it's simply the storage we desperately need.
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.
So I could recover previously saved versions of e.g. a word-processing file? Used to use that back per-millennium on a Novel network with shared drives and it was very useful indeed. I've always wondered why that feature wasn't available in later systems.
Yes and not only, you can see file history, just like commit history in git&c, you can compute diff on-the-fly both for single file and entire trees, you can "undo" last write etc
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.
Yep, I mean compared to zfs live dedup it use less ram but generate an I/O load similar to a full resilvering... In that sense from my point of view it's "intensive", however consider that I only play with it, I do not have a solid idea on how it can be in real world scenarios...
This is all accurate. It's a FreeBSD 4 fork that targets amd64 exclusively. (The latest FreeBSD release is 12.0.)
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.
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!