DragonFlyBSD's HAMMER2 File-System Being Ported To NetBSD

[curfew]

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.

XFS really is a poor example. It was first released back in 1994 for IRIX and ported to Linux in 2001, when the company behind IRIX was migrating its own services to Linux. Basically XFS was not gaining support for more platforms, the whole filesystem was being migrated from IRIX to Linux permanently. Technically XFS is also supported on FreeBSD but it's read-only, and apparently support for it has been somewhat phasing out as they kicked out the native kernel module and now XFS is only available via FUSE.

At the time of being ported from IRIX to Linux, XFS was (still is) also much simpler than ZFS or HAMMER2.

[oiaohm]

XFS really is a poor example.

https://wiki.netbsd.org/projects/project/xfs/

Its not quite as poor of example as one would think. XFS upstream being GPL license. Short term there was decent results. Long term XFS upstream license killed it on other platforms as kernel module.

Remember XFS was technically better than all the file systems BSDs had at the time then it got caught up with and the BSD interest in XFS faded away.

apparently support for it has been somewhat phasing out as they kicked out the native kernel module and now XFS is only available via FUSE.

Google vs Oracle case comes into play. Or Google using Harmony java implementation being apache license vs Oracle/sun implementation being LGPL with harmony seaming to lose in court because they used LGPL licensed documentation. Pushing XFS out to fuse means a XFS license issue cannot effect the FreeBSD core. Summer of code 2021 freebsd backed creating a new XFS implementation in rust using fuse.

The kicked out native kernel module of XFS you have to wonder if the point will come due to some court case that OpenZFS is too risky to have a BSD kernel module so also be forced to pure fuse.

At the time of being ported from IRIX to Linux, XFS was (still is) also much simpler than ZFS or HAMMER2.

XFS platform porting history shows a lot of fatal problems. Some of these fatal problems apply to OpenZFS particularly the license one.

XFS platform porting has everything you can do right and everything you can do wrong. So XFS is a very complete example covering the good and bad that can happen. There are other examples that can be picked that went basically perfectly. Normally BSD license file systems that went perfectly being ported between platforms due to no major license issues.

[ryao]

https://wiki.netbsd.org/wiki/RootOnZFS/

It sounds like it works if you use GRUB2.

[ryao]

LOL, didn't Mat Dillon explained, that this is technical not possible, because of missing features in FreeBSD?

Matthew Dillion implemented concurrency in the kernel in a way that avoided locks in places where any other system would have used fine grained locks. The result is that DragonFlyBSD kernel code lacks locking in places where locking is necessary in other operating systems. That should not pose too much of a problem for doing a readonly port like was done here:

https://github.com/kusumi/freebsd_hammer2

[oiaohm]

It sounds like it works if you use GRUB2.

https://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=56677

No ryao just because documentation exists that tells you how todo stuff does not mean it works well. Yes 2022 fun little issue of not being able to load firmware from other drivers in NetBSD kernel turned up if you run ZFS root. ZFS lack of kernel integration causes some horrible issues.

Other problems like this have been turning up as well. NetBSD has a stack of issue running root as ZFS that purely happen because OpenZFS cannot be mainlined so its not hooked in where other drivers expect it to be.

Ryao you OpenZFS developers need to serous-ally take off your rose color glasses. Its not just Linux kernel developers who are having issues because OpenZFS cannot be mainlined. BSD are having issues with OpenZFS because it cannot be mainlined so is not hooked into the OS in ways other drivers expect yes like cannot load firmware bugs. Yes these are the same kind of problems that end up ruining Ubuntu/Canonical day over and over again OpenZFS root usage and why they are walking way from it.

You can bet at some point NetBSD developers will run out of tolerance as well as this issues keep on turning up.

Ryao its about time OpenZFS developers admit they are attempting to use false facts and Fomo marketing instead of facing up to the problems the CDDL license and lack of kernel integration into operating systems are causing.

Ryao you complained about me using false facts in reality you do it all the time about ZFS.
1) Like the sales pitch that Ubuntu fixed the ZFS issue by having the distribution build the module with kernel that is not fact.
2) Or the other sales pitch we don't have a license problem with BSD so Linux distributions should work out how to accept OpenZFS.
Both of those are false.

License problem effects BSD kernels as well because it blocks mainlining.

I now expect to see false flags saying since NetBSD gets it to work all the other BSD and Linux should be able to get it work completely ignoring the issues that keep on turning up with NetBSD due to the CDDL license not being correctly compatible with the BSD license resulting in improper integration.