Hacker News Reader

Comment by harikb | Hacker News Reader

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?

View on HN

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.

Even the performance claims do not really hold up anymore. Freebsd in general performs better and not surprising since it has so many more resources.

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 :(

> HAMMER's ability to snapshot an arbitrary directory is still something I deeply deeply deeply respect & wish btrfs or zfs had.

AFAICT, this is doable in btrfs by creating a new volume and then snapshotting that.

>marginally worse performance

What benchmarks are you people talking about?

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.

https://www.phoronix.com/scan.php?page=article&item=comet-la...

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.

I somehow suspected so. These are terribly poorly chosen benchmarks.

They test compilers, which tend to be older on BSDs; They are more conservative with updating them.

They seldom if at all test SMP scalability, parallel io, network throughput and latency or even scheduler latency. That is where the meat is.

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.

http://www.brendangregg.com/ActiveBenchmarking/bonnie++.html provides an example how "the same benchmark" can measure a different thing on a different platform.

Have you tested that or just read those terrible phoronix benchmarks?

What is clustering in this context?

"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.

For an OS that achieved this look at OpenVMS https://vmssoftware.com/products/clusters/ https://en.wikipedia.org/wiki/VMScluster

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.

Linux had this capability through MOSIX https://en.wikipedia.org/wiki/MOSIX which was open source, and then continued to be via OpenMOSIX

Reply on news.ycombinator.com