DragonFlyBSD's HAMMER2 File-System Being Ported To NetBSD

[oiaohm]

Indeed. Same with ZFS. Infact, FreeBSD has a solaris.ko (kernel module) just for these additions.

I am glad to hear hammer is getting ported. Mainly because if you port it once, it helps you clean up some of the encapsulation and API making it easier to port to further operating systems.

As it the case with most things getting ported from foreign systems. On Linux this used to be achieved thanks to the Solaris Porting Layer (SPL) which resided on a its own repository and has been merged into ZFS.

Both need to remember what OpenZFS does is not what normally happens.

HAMMER2 is not a incompatible license. Also DragonFlyBSD is a fork off FreeBSD 4.8. Yes current Freebsd is 12.4 so it a long way back. This is not a case of complete foreign OS design.

[curfew]

I suppose porting to FreeBSD involves adding the missing features.

One of the documented issues was that DragonFlyBSD has more advanced locking mechanism that is used with multithreading. This sounds like a very low-level OS intricacy and I don't think that just getting one foreign filesystem to work justifies such patches, since it could involve a lot of headaches if it blows up.

Also hard to envision that the original authors would let some outsider rewrite parts of the FS code to remove dependencies to the "native" OS so that the filesystem could run on other platforms... That could, again, blow up the FS on all platforms.

[Classical]

How good is HAMMER2 compared to other file systems such as ext4, ZFS, Btrfs, and Apple File System (APFS)?
Are they similar in design or does HAMMER2 provide any advantages?
Has there been any interest to port HAMMER2 to Linux? I think it would be difficult because Linux and DragonFly BSD differ in the VFS.

There is more demand for ZFS than HAMMER2 in Ubuntu anyway, and we see that their efforts for ZFS were not enough and that they will focus more on other things in the future. So it seems that Ubuntu won't get a top-notch ZFS implementation in the near future, and they might stop supporting ZFS. I think maybe they just don't have the skills to optimally implement this kind of advanced technology.

NixOS and Void Linux currently have better ZFS support than Ubuntu, maybe one of the distros where they have more skills can implement HAMMER2, but it probably won't be an easy task.

How good HAMMER2 is will depend from situation to situation. For popular databases like PostgreSQL and SQLite, I think HAMMER2 is faster in most situations than any of the other file systems currently in existence. So it has unparalleled performance in many SQL databases. Here's a review of the old HAMMER:

HAMMER good
-Fine grained journaling with HAMMER history beat a pants out of everything around.
-HAMMER has high focus on data integrity.
-Backup ready having network aware hammer-snapshot/hammer-stream.
-Phenomenal performance with SQL.
-Much lower RAM requirements for HAMMER de-duplication than ZFS.
-Pseudo-Filesystems (PFSs).
-Fully open source with nice BSD license attached to it
-It is possible to share HAMMER via NFS.

HAMMER bad
-No self healing.
-No compression.
-No volume growing.
-mirror-snapshot/stream are read only and require human intervention to be deployed.
-PFS can't be used as iSCSI target.

https://oda.oslomet.no/oda-xmlui/bit...?sequence=2&is Allowed=y

Conclusion:
This study of file system snapshots has shown that read- and write performance is affected when the number of snapshots increase. By optimising the snapshot count for performance, system administrators can use snapshots to apply packages and updates to the operating system, which can be rolled back to the previously working state if they do not meet required specifications. By using snapshots, system configuration tools can be simplified and use the file system directly to query the history of the system’s configuration. This can improve system reliability and security by making programs simpler, with fewer parts which can fail. However, snapshots come with a cost. Snapshots decrease file system performance significantly in a short time. Creating a policy for using snapshots require careful considerations of the data’s importance and update frequency. Considering snapshot creation interval a function of data update frequency, where the creation interval decrease as the update frequency increase; frequently updated data have a higher cost. The results from this work show that performance quickly decreases towards zero on ZFS, but before this, there is a point where the system turns unstable. Low performance is not desirable, but if the system is unstable, it is unreliable too. It is important that future research study this problem, so it can be improved, or revealed that it came from experimental error. Space utilisation is linear up to the point the system goes unstable, where it starts to grow. Hammer’s performance also decrease significantly, but there are no suggestions that the system is going towards a point where it will go unstable. The results for some modes of access look a bit strange; further studies are required to explain this. Space utilisation does not appear to be linear, but his might be the result of experimental error. The method for benchmarking Hammer has to be revised before this phenomenon can be studied more closely.

Notice that HAMMER is not enterprise file system suitable for large data farms according to Matt himself.
But I think that the innovations that have been implemented in HAMMER2 have made it suitable for enterprises.

[oiaohm]

One of the documented issues was that DragonFlyBSD has more advanced locking mechanism that is used with multithreading. This sounds like a very low-level OS intricacy and I don't think that just getting one foreign filesystem to work justifies such patches, since it could involve a lot of headaches if it blows up.

NetBSD also is less advanced locking than DragonFlyBSD

Also hard to envision that the original authors would let some outsider rewrite parts of the FS code to remove dependencies to the "native" OS so that the filesystem could run on other platforms... That could, again, blow up the FS on all platforms.

https://github.com/kusumi/netbsd_hammer2

Same author freebsd

https://github.com/kusumi/freebsd_hammer2

The original author of hammer2 with the netbsd or freebsd has no means to veto because both of these are legally allowed fork. This is more the traditional way of porting drivers particularly when the license is compatible. Import the driver by making it use the features of the driver it going to be targeted at. None of this make abstraction layer stuff the OpenZFS developers love doing.

curfew why cannot the ported driver be a native driver for the platform it been ported to.

Not being a complete case of foreign OS means that segments of the DragonFlyBSD driver on Freebsd and netbsd most likely does not need to change.

This could get interesting OpenZFS on bsd platforms could find themselves competing against a OS native file system with no abstraction overhead providing basically the same feature set with Hammer2.

Now the issue of not being mainline-able due to license I do suspect to raise it ugly head with OpenZFS in future on BSD platforms as well.

Hammer2 license does mean it could be ported into a native Linux kernel driver as well. Feature set and License makes Hammer2 very interesting particularly with the fact BSD license is highly compatible to being native ported and mainlined into every major OS.

[oiaohm]

There is more demand for ZFS than HAMMER2 in Ubuntu anyway, and we see that their efforts for ZFS were not enough and that they will focus more on other things in the future. So it seems that Ubuntu won't get a top-notch ZFS implementation in the near future, and they might stop supporting ZFS. I think maybe they just don't have the skills to optimally implement this kind of advanced technology.

NixOS and Void Linux currently have better ZFS support than Ubuntu, maybe one of the distros where they have more skills can implement HAMMER2, but it probably won't be an easy task.

https://nixos.wiki/wiki/ZFS ZFS has it fair share of issues with NixOS with kernel updates that they nicely document. Void Linux documentation on ZFS skips over the you want to update kernel you are running ZFS sorry at times you will not be able to.

Classical maybe the ZFS license problem is way worse than one thinks. Think about needing the Solaris abstraction layer and having to keep that in lock step with upstream kernel changes that OpenZFS causes. I would not say that its an advanced technology. CDDL was designed to be GPL incompatible and this causes lot of problems. CDDL is not perfectly compatible with BSD kernel license either.

https://www.kernel.org/doc/html/latest/dev-tools/coccinelle.html

There is a very big advantage of being mainline in the Linux and BSD kernels. Under Linux a developer doing invasive change can write smpl patch to locate all effected parts and contact the maintainers of those parts for feedback if the work is mainline. BSD kernel developers have the there own ways of doing the same things.

Out of mainline kernel abstraction layer like OpenZFS has will not show up in those searches.

The original hammer file system port to Linux kernel level died then there was a fuse version for awhile.

[curfew]

curfew why cannot the ported driver be a native driver for the platform it been ported to.

Well, I was kind of assuming that they would share development in a similar fashion to how OpenZFS is managed right now. Completely forking complex filesystems seems like a scary thing to me, since then you will need to put the same immense labour into porting and thoroughly evaluating every single new feature that the original codebase obtains.

[oiaohm]

Well, I was kind of assuming that they would share development in a similar fashion to how OpenZFS is managed right now. Completely forking complex filesystems seems like a scary thing to me, since then you will need to put the same immense labour into porting and thoroughly evaluating every single new feature that the original codebase obtains.

XFS history of being ported to many OS by the same method as each OS doing their own driver did in fact have unified testsuite. Also for a lot of test XFS test suite can be used generically.

https://github.com/kusumi/hammer2 there note on possible road map for Linux kernel version.
All the existing ports of hammer2 are they are following the native per OS route.

Hammer2 also has does 1 new specification a year max so rate of new feature is limited so this is a file system that could be very suitable for the native driver per OS.

OpenZFS current model means you have to maintain abstraction layer. Evaluating every support OS kernel new added features to keep OpenZFS abstraction layer aligned is not a light process this is why OpenZFS very commonly has cases of don't work with X version kernels until OpenZFS updates. And the abstraction layer can result in not using the OS most effective way of doing something.

curfew both routes have downside. The horrible point is the costs of the OpenZFS way could be higher than the advantages. We have not had a cow file system try multi OS support native to have a solid benchmark on what that cost is. Historically with file systems like XFS it was better to avoid abstraction layer because it end up too costly.

[phoenix_rizzen]

"in NetBSD-CURRENT is the ability to use ZFS as the root file-system if first booting to FFS" sounds like a contradiction to me. I think it means to say its not currently possible to boot directly from ZFS root in netbsd ie you need a FFS boot partition?

It's not a contradiction, it's just awkwardly worded.

You can use ZFS for the root filesystem, but you can't boot from it. Thus, you need to have /boot on an FFS filesystem, where the boot loader and kernel reside, which can then import the ZFS pool and mount the root filesystem.

All that's missing is the ability to import ZFS pool and locate the kernel in the NetBSD boot loader.

FreeBSD went through a similar process, where you needed a UFS filesystem for /boot but could have ZFS for the root filesystem. Once the FreeBSD loader gained support for ZFS, you could boot directly from ZFS.

[archkde]

One of the documented issues was that DragonFlyBSD has more advanced locking mechanism that is used with multithreading. This sounds like a very low-level OS intricacy and I don't think that just getting one foreign filesystem to work justifies such patches, since it could involve a lot of headaches if it blows up.

If it's really a locking mechanism and not some crazy stuff like RCU, it shouldn't be too bad. They are not too complex to implement once the primitives are there, and most can be built on top of mutexes (although this is usually not the most optimal way).

Also hard to envision that the original authors would let some outsider rewrite parts of the FS code to remove dependencies to the "native" OS so that the filesystem could run on other platforms... That could, again, blow up the FS on all platforms.

I can imagine the FreeBSD port lives in a fork for now, so it won't mess up anything. I don't see why the original author would have a problem with that. Not that it would matter much from a legal perspective, since DragonFlyBSD is free software under the BSD license.

[archkde]

https://nixos.wiki/wiki/ZFS ZFS has it fair share of issues with NixOS with kernel updates that they nicely document. Void Linux documentation on ZFS skips over the you want to update kernel you are running ZFS sorry at times you will not be able to.

Well, it's basically the same issues as on every other Linux distro, just that NixOS documents it better. ZFS not working with latest kernels (which, admittedly, some distros avoid by shipping old kernels to begin with), and breaking fatally with hibernation, are both well-known problems. That's what you get for using an out-of-tree filesystem that can't even use kernel interfaces properly because of license issues.