[spijdar]

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

[rektide]

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.

[zozbot234]

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

[spijdar]

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

[snvzz]

>marginally worse performance

What benchmarks are you people talking about?

[spijdar]

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.

[pikrzyszto]

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.

[snvzz]

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.