In case anyone wants a background on what Dragonfly vs FreeBSD
> The ultimate goal of the DragonFly project at its inception was to provide native clustering support in the kernel. ... While full cache coherency is no longer a top level goal, filesystem coherency is, and that direction continues to guide the project in a number of ways.
> DragonFly BSD was forked from FreeBSD 4.8 in June of 2003, by Matthew Dillon. The project was originally billed as "the logical continuation of the FreeBSD 4.x series", as quoted in the announcement, but this description has long since become obsolete. From a performance perspective DragonFly's only real competitor these days is Linux
Are there any real world success stories with this?
This brings backs memories... I still used FreeBSD by then, and I remember that the 5.x branch really had problems and the drama that surrounded it in the community.
I started using FreeBSD(4.3 or 4.4) in the Uni out of curiosity, but kept it for the massive improvement in performance and stability. Loads that brought Linux to its knees(>10) were handled easily by FreeBSD.
The documentation was also superb... the only drawback was having to compile everything, never got used to it.
Yeah, with all due respect to the developers (because getting as far as they have is a huge accomplishment!) the biggest feature of DFly I can identify is HAMMER, which is most interesting if you don't want to use ZFS for license reasons.
I remember some of the old goals were things like process snapshotting and transferring, as in saving a process state and transferring it to another machine. It seems most of these ambitions ended up discarded, which is a shame, since it's increasingly becoming a "FreeBSD, but with fewer features, more incompatibilities, and marginally worse performance" :(
HAMMER's ability to snapshot an arbitrary directory is still something I deeply deeply deeply respect & wish btrfs or zfs had.
I'm not sure the status but HAMMERFS also supposedly was going to have solid transparent encryption, which is something I wish btrfs did. I'd really like to be able to take a fs snapshot, send it to a friend, have them load the snapshot volume, but be unable to access it. But as soon as I did show up at their place with my keys, we could instantly unlock it & use it. I understand ZFS does a better job of this all, but balancing ZFS pools & adding drives has always sounded impossibly hard compared to btrfs's "it just works" adding-drives to RAID scenarios.
Ahh, that does sound like a nifty feature! I didn't mean to so strongly imply HAMMER was a knock-off ZFS, more that it fills a similar niche, similar enough that ZFS's dominance kind of takes away from the "wow factor" of HAMMER.
It makes more sense (to me anyway) when you consider that at the time HAMMER was first released, the Linux port of ZFS had only just begun, and FreeBSD had just released their first port of ZFS. Btrfs was also still an out-of-tree patch then, only mainlined in 2009. (not to mention ZFS as a whole probably seemed much more shaky around 2010 with Sun's death-by-Oracle and OpenSolaris getting butchered)
I think back then, having a clean and functional "recreation" of ZFS with all the design bloat removed seemed really promising. Now, it's just a nice FS competing with other nice FSes, except with the downside of being on an "exotic OS". Shame :(
I'm thinking of a few Phoronix benchmarks I've seen through the years. I'm not going to pretend like these benchmarks are the be all and end all, but I do think it (at the very minimum) compares run-times for common tasks.
In general, Linux comes out on top, FreeBSD follows, and Dragonfly takes third place. In some instances, Dragonfly beats out FreeBSD, but only just. The overall mean is that Dragonfly is only sightly worse than FreeBSD.
Again, not advocating for using phoronix benchmarks like it proves anything, but I think these results make sense.
It's hard to reliably reproduce a cross-platform benchmark. They use different compilers, different compiler flags and do not show profiles. Also some compilers tend to be quite conservative in less-known environments.
"Single system image" clustering - or in plain language, a single operating system running distributed on top of a bunch of (often commodity) hardware.
Your program runs just like it would on a single PC. The OS is designed to ensure that it functions correctly regardless of which underlying resources are doing the compute.
It's worth noting that Linux is picking up a lot of the basic infrastructure needed to enable this, if only as an unexpected side-development of earlier work wrt. containerization and namespacing of all system resources. Check out the CRIU (Checkpoint and Restore In Userspace) patchset.
> The ultimate goal of the DragonFly project at its inception was to provide native clustering support in the kernel. ... While full cache coherency is no longer a top level goal, filesystem coherency is, and that direction continues to guide the project in a number of ways.
> DragonFly BSD was forked from FreeBSD 4.8 in June of 2003, by Matthew Dillon. The project was originally billed as "the logical continuation of the FreeBSD 4.x series", as quoted in the announcement, but this description has long since become obsolete. From a performance perspective DragonFly's only real competitor these days is Linux
Are there any real world success stories with this?