DragonFlyBSD lead developer Matthew Dillon has recently been working on further refinements to HAMMER2 for the next DragonFlyBSD operating system release.
The latest HAMMER2 activity in the past few days has included improving its CPU performance and adding a new “hammer2 recover” directive. The HAMMER2 recover support allows for recovering/undoing single files as well as preliminary support to recover entire directory structures.
DragonFlyBSD always feels like the one nobody talks about or uses, with FreeBSD, OpenBSD and NetBSD taking the spotlight instead. Are any of you folks using it? How has it been?
Does anyone actually use DragonflyBSD?
I’ve tried a few times to use it as a workstation OS and it’s not very desktop-friendly. I can definitely see the potential as a server OS, but I don’t have a use case for it in that mode; I use OpenBSD for that for the better (in my opinion) built in tooling.
Yeah, I’ve had it as a personal server and I’ve run various benchmarks before. The problem is no one really tunes their apps for it, and there is zero support that companies trust. So it has to be insanely better than everything else, or its just not going to be approved for production use.
Don’t hold me to this, but I don’t think Matt’s vision is as a workstation per say, but more along the lines of a VMS replacement for clustering solution. Not sure if anyone here is worked with a VMS cluster, but they are sight of beauty even if they are an aged technology by today’s standards. One of my previous employers was heavily invested in VMS, and they had a cluster with an uptime of over a decade with a mix of MIPS and Alpha systems I believe. The through-put processing capabilities of a VMS system were only eclipsed by a mainframe, but that was like 15 years ago so that might not be true today.
I’m not sure we will ever see HAMMER2 brought to other OS’s because he has tuned both the filesystem to the kernel and the kernel to the filesystem meaning the two really can’t be separated as far as I can tell so mileage will vary on that statement.
This is generally true of most filesystems, and is why bringing ZFS to kernels that aren’t Solaris/Illumos usually requires also bring the “opensolaris” kernel module, which is a large amount of Solaris source code (mostly the memory management and virtual memory system, but also some of the VFS layer and some thread handling). For any non-trivial filesystem, it takes a tremendous amount of effort to port to a new kernel. Similarly at one point when people were talking about stolen UNIX code in Linux, a lot of the files of concern were parts of SGI IRIX, needed for the XFS filesystem code to function. That was intentionally imported, with appropriate licensing performed.
I’ll have to try ZFS next, but I’ve been testing out btrfs as a more modern alternative to mdraid + lvm. I find the ability to add and rebalance media without overly concerning oneself with paired disk sizes is extremely compelling also the ability to hash file contents and scrub them is very nice too. But in my testing of disk failures the btrfs handling of failures is abysmal. It cannot handle a full disk, the btrfs volume WILL go down and it needs to be taken care of manually. On a boot disk the results would be devastating running at a remote data center without console access.
Not too long ago I experienced a degraded mdraid array and…there was no downtime at all, it kept working as intended!!! This is exactly what raid needs to do and btrfs’s failure makes it completely unacceptable for any production system that needs to stay online. You can technically run btrfs ontop of mdraid, which would help mitigate it’s flaws, but you loose all of btrfs’s benefits by doing so. I was looking forward to incorporate btrfs into my stack, but the way it handles raid failures leaves btrfs unfit for production.
I want to try ZFS next, but the lack of mainline support is off-putting for me. I will need to make it work with my own distro and the lack of ABI stability in linux increases the workload to support out of tree kernel modules. I’ve been there and done that, it’s just not something I look forward to. That aside, ZFS should pass my raid tests with flying colors. As I understand it ZFS isn’t quite as flexible as btrfs in provisioning disks. Whereas btrfs allows changing raid levels and disks at will, ZFS requires rebuilding arrays. This isn’t ideal, but coming from mdraid I believe the raid capabilities are similar..
Anyone looking at these file systems for their checksum capabilities may be interesting in dm-integrity, which works with mdraid.
https://securitypitfalls.wordpress.com/2020/09/27/making-raid-work-dm-integrity-with-md-raid/
The main purpose of high level checksums is to be able to do something about silent data corruption where a disk returns sector data without detecting an error itself. This occurrence is statistically rare as ECC is designed to detect it, especially with enterprise hardware. Still, higher level checksums done in software will provide more redundancy.
https://serverfault.com/questions/696216/hard-disk-ssds-detection-and-handling-of-errors-is-silent-data-corruption