DragonFlyBSD's HAMMER2 File-System Seeing New Improvements, Initial Recovery Support

[phoronix]

Phoronix: DragonFlyBSD's HAMMER2 File-System Seeing New Improvements, Initial Recovery Support

When it comes to the BSD operating systems, DragonFlyBSD's HAMMER2 is one of the most interesting innovations. HAMMER2 supports online deduplication, clustering, multiple mountable file-system roots, snapshots, compression, encryption, extensive checksumming, and other features. Over the past decade it's evolved quite nicely and in recent days has seen further enhancements...

https://www.phoronix.com/news/DragonFlyBSD-Better-HAMMER2

[skeevy420]

I wish this was available for more operating systems because, IMHO, this and OpenZFS are the best file systems around in regards to feature flexibility, but the choice of being limited to one FOSS operating system versus having the option to pick between three families of FOSS operating systems (Linux, BSD, Solaris) isn't much of a choice at all.

[evert_mouw]

I wish this was available for more operating systems because, IMHO, this and OpenZFS are the best file systems around in regards to feature flexibility, but the choice of being limited to one FOSS operating system versus having the option to pick between three families of FOSS operating systems (Linux, BSD, Solaris) isn't much of a choice at all.

True. On a positive note, it seems DragonflyBSD (partly) supports virtion. I've one test VM with dragonfly running in QEMU/KVM with virtio drive and network. In theory, I could share a disk with the VM and enable NFS and SMB on the dragonfly. In practice, I use OpenZFS for my important data and also my hopes are high for bcachefs. (And then there's btrfs, it seems to catch up a bit.) HAMMER2 is unique with (planned) clustering support.

[skeevy420]

True. On a positive note, it seems DragonflyBSD (partly) supports virtion. I've one test VM with dragonfly running in QEMU/KVM with virtio drive and network. In theory, I could share a disk with the VM and enable NFS and SMB on the dragonfly. In practice, I use OpenZFS for my important data and also my hopes are high for bcachefs. (And then there's btrfs, it seems to catch up a bit.) HAMMER2 is unique with (planned) clustering support.

Having to setup a VM with esoteric setups for every distro hop is why I didn't pick HAMMER2 years back. It's just easier when a non-native FS is a repo install or a DKMS build away from working.

I, too, have high hopes for bcachefs. The irony is that now that Linux is getting a FS that I think competes with OpenZFS, OpenZFS has gained even more features and more distribution support that it makes bcachefs seem less appealing to me than it actually is. Damn shame I'm that jaded about it. While it's a total game changer for those that use "Linux Native" tooling, it's mostly a downgrade from OpenZFS so I really hope that bcachefs feature development picks up once it becomes mainlined and gets more exposure.

[blackiwid]

How is it better than bcachefs and btrfs? Except that it's only available on this exotic specific version of bsd, that use probably 5000 people in the world?

Now the 2 mentioned might not have all features thinkable, even the mentioned in this article I think they both have, so you can maybe make the argument that somehow btrfs is bad, fine then you have bcachefs that solves this, I don't see the case except that some people 10 years ago had problems with it.

We can bitch about tooling, but that has not to much to do with the FS itself. So except another FS that brings nothing over the other COW filesystems I don't see any appeal in that.

[evert_mouw]

How is it better than bcachefs and btrfs? Except that it's only available on this exotic specific version of bsd, that use probably 5000 people in the world?

Now the 2 mentioned might not have all features thinkable, even the mentioned in this article I think they both have, so you can maybe make the argument that somehow btrfs is bad, fine then you have bcachefs that solves this, I don't see the case except that some people 10 years ago had problems with it.

We can bitch about tooling, but that has not to much to do with the FS itself. So except another FS that brings nothing over the other COW filesystems I don't see any appeal in that.

I mostly agree (especially about the promising bcachefs) but still HAMMER2 is interesting with clustering and multiple mount support, also the DragonFlyBSD guys do interesting technical work in general, and HAMMER2 seems to be stable enough for a few years already. Sure it is exotic, maybe not for production but for fun...

[skeevy420]

How is it better than bcachefs and btrfs? Except that it's only available on this exotic specific version of bsd, that use probably 5000 people in the world?

Now the 2 mentioned might not have all features thinkable, even the mentioned in this article I think they both have, so you can maybe make the argument that somehow btrfs is bad, fine then you have bcachefs that solves this, I don't see the case except that some people 10 years ago had problems with it.

We can bitch about tooling, but that has not to much to do with the FS itself. So except another FS that brings nothing over the other COW filesystems I don't see any appeal in that.

In the case of BTRFS, all the datasets have the same mount options which can be very unoptimal. Take compression. You're stuck with Zstd:# or Gzip for everything. That's not necessarily the best for /var and other active read/write directories where a codec like LZ4 or LZO would work better. With bcachefs, you don't have multiple datasets per pool. It's more of a one disk(s) per dataset/pool in its current state. You'd need fixed partitions or a separate disk to handle /var's compression with either of them.

HAMMER2 and OpenZFS allow giving multiple datasets in the same pool different mount options, though HAMMER2 doesn't have as many options as OpenZFS. For me, that's the deal breaker with most other file systems that have dataset-like features; they're so limited that (LUKS2+)LVM2+"the best file system for the job for a particular mount point" is almost always the more robust and optimal solution....or just a single FS like OpenZFS or HAMMER2 that allows extensive datatset layouts on a single pool with shared data usage; no sparse layouts or worrying about partition allocation.

Pardon me for using OpenZFS terminology.

[S.Pam]

In the case of BTRFS, all the datasets have the same mount options which can be very unoptimal. Take compression. You're stuck with Zstd:# or Gzip for everything. That's not necessarily the best for /var and other active read/write directories where a codec like LZ4 or LZO would work better. With bcachefs, you don't have multiple datasets per pool. It's more of a one disk(s) per dataset/pool in its current state. You'd need fixed partitions or a separate disk to handle /var's compression with either of them.

HAMMER2 and OpenZFS allow giving multiple datasets in the same pool different mount options, though HAMMER2 doesn't have as many options as OpenZFS. For me, that's the deal breaker with most other file systems that have dataset-like features; they're so limited that (LUKS2+)LVM2+"the best file system for the job for a particular mount point" is almost always the more robust and optimal solution....or just a single FS like OpenZFS or HAMMER2 that allows extensive datatset layouts on a single pool with shared data usage; no sparse layouts or worrying about partition allocation.

Pardon me for using OpenZFS terminology.

With btrfs it is possible to set compression type per file using `btrfs property set <file> compresssion (zstd|lzo|gzip)`

Datasets don't quite work the same in Btrfs. There you would use subvolumes.

That said. I think it is good with some diversity

[kylew77]

Wish more *BSDs would adopt support for this. Read awhile back that NetBSD was working on read only Hammer 2 and FreeBSD had an article about support coming in one of the last three or so quarterly reports. I know OpenBSD is eyeing support as well Eventually which could be a decade or more!

[skeevy420]

With btrfs it is possible to set compression type per file using `btrfs property set <file> compresssion (zstd|lzo|gzip)`

Datasets don't quite work the same in Btrfs. There you would use subvolumes.

That's the issue. That doesn't work with programs that add/remove data as necessary, like a package manager with its cache. Subvolumes inherit the parent codec so someone would have to have to have some sort of a "btrfs property set <file> codec" daemon constantly running and pointed towards anywhere that doesn't use the primary volume's codec. IMHO, that's not an ideal setup.

Note that we're only talking about the file codec. There are other features like checksumming, how metadata is handled, etc that can also have those same subvolume limitations.

That said. I think it is good with some diversity

Agreed on that. Diversity encourages competition which drives advancements.