Hacker News Reader

Comment by mappu | Hacker News Reader

I don't think the parts about ZFS being "better integrated" on FreeBSD are really true any more.

For one thing, ZFS-on-Linux is now the canonical, upstream OpenZFS implementation - https://utcc.utoronto.ca/~cks/space/blog/solaris/ZFSOnLinuxN...

For another, Ars Technica recently reviewed FreeBSD 12.1-RELEASE and found poor ZFS integration in the installer and in mount(8):

> Eventually, I realized that FreeBSD's mount command didn't really understand my ZFS root filesystem. -- https://arstechnica.com/gadgets/2020/04/not-actually-linux-d...

Compare that with the relatively streamlined ZFS-on-root install support built into Ubuntu: https://arstechnica.com/information-technology/2019/10/a-det...

(I'm sticking with ext4 until kvdo, bcachefs, or maybe tux3 is mainlined.)

View on HN

> Eventually, I realized that FreeBSD's mount command didn't really understand my ZFS root filesystem.

I couldn't find this direct quote in your link. But I'm using FreeBSD with ZFS on a few machines and I don't understand this comment.

You can absolutely boot with ZFS on root. The installer lets you do it out of the box. Including with geli for encryption.

And you can use mount(8) to mount a ZFS partition, I have done that all the time when booting from recovery media and mounting my root pool. This gets a little confusing at first because most uses of mount(8) require a device name, and mounting ZFS takes a pool name, so you may have to zpool import first, but once you get over that it's fine.

The quote appears in the article, on page 3 after some lazy-loading (do you have Javascript enabled?)

Ah ok, this is about trying to remount read-write. Yes, that requires zfs set readonly=off on FreeBSD. [vs. -o rw with mount(8)].

Actually zfs mount -u / works just fine.

But I think the complaint is that it doesn't happen through mount(8).

> I don't think the parts about ZFS being "better integrated" on FreeBSD are really true any more.

ZoL is not in the mainline Linux kernel, therefore it isn't even "integrated". Linux 5.x introduced some backwards incompatible changes which broke ZoL also triggering a response from Linus.

https://www.phoronix.com/scan.php?page=news_item&px=Linus-Sa...

For these reasons I'm also going to stick with ext4 on Linux. In the meantime we run appliances and servers which run ZFS on FreeBSD without any issues. SmartOS is another choice to run ZFS but I don't have any experience using it. Maybe I'll try it as an alternative to Proxmox.

> (I'm sticking with ext4 until kvdo, bcachefs, or maybe tux3 is mainlined.)

I haven't heard of kvdo before - thanks for bringing it up!

I'll add stratis-storage to this mix too. (Although I'm contributing to the bcachefs development and really want it to succeed)

The Linux kernel devs hate ZFS and actively sabotage it even backporting changes specifically to break ZFS to LTS branches.

It's fine if you use something like Ubuntu where it's officially shipped with the distro. If not, be prepared to apply kernel patches whenever the kernel team takes a snipe at ZFS.

I'm not trying to be political here, just my day-to-day experience working with several Linux machines running large zpools. It's still worth it compared to the alternatives but if I could use FreeBSD I would.

The Void team does a good job with managing ZFS as well (it's in the official repos). The unofficial ZFS on Arch is generally ok as well (though Arch's management of kernels is weird and a bit tricky).

Do you have an example of a commit where they did this? Just curious as to how (no need to explain why, I get it)

See https://github.com/openzfs/zfs/issues/8259 for details.

While they didn't remove it to sabotage ZFS, they don't seem to care about it ruining ZFS performance on Linux.

Of course they have no obligation to make ZFS on Linux users happy, still a bit of a bummer tho.

It looks like Linux kernel devs just don't care about ZFS, like they don't care about many out-of-tree kernel patches/modules.

There's absolutely no evidence for this. On the other hand, there's some evidence that Sun made ZFS licensing explicitly non-compatible with the GPL, so as to not "sabotage" Solaris.

Linux has other efforts going on in this area, including Btrfs and Bcachefs - there's also ZoL, of course.

Take a look at any of Greg Kroah-Hartman's comments on patches that screw up ZFS.

One of the biggest ones was removing exports of kernel functions that ZFS used for encrypted datasets: https://marc.info/?l=linux-kernel&m=154689892914091

I'm fine with this sort of stuff in general assuming it doesn't affect LTS, but this specific patch was backported to LTS kernels even though it has nothing to do with security or bugfixes. I had several zpools I had to apply custom kernel patches on the machines for no other reason than because somebody is mad at licensing.

Bcachefs isn't even stable enough to use in production. Btrfs is okay, and I've used it before, but it's also a minefield of killing your data depending on what features you use. If you use all the features you need to make it on par with ZFS you may as well dump your data in the trash.

ZFS 'just works' and none of the features are incomplete or have asterisks attached that compromise data integrity. Yeah it has architectural problems, doesn't do stuff the Linux way, and has a license that makes devs angry. It's also never lost a byte for me in production for almost a decade of use.

I know the Linux devs don't owe me anything and I'm not really angry or anything about this. It's just a fact that it's frustrating to have to deal with political problems just to run a server.

You're just ignoring what I said above. Nobody is out to screw ZoL, but the kernel community doesn't care enough to maintain compatibility with it.

Why, as a kernel dev, would you care if there's no possibility of it ever being mainlined because of decisions Sun explicitly made to be hostile towards your project?

It's like trying to cozy up to someone who just punched me, not happening.

Bcachefs isn't yet up to parity for sure, but it is stable enough for everyday use and doesn't corrupt you data like Btrfs sometimes does. A stable foundation that gets expanded upon daily.

why not use zfs, since it does the things that kvdo, bcachefs, and tux3?

Only one reason of Oracle law suite sword hanging over neck. Even if canonical gives guarantee they will fight with Oracle, if a small company is dragged by oracle in a court room it's hard to fathom the expenses.

So yes there is a need for zfs alternative. So far stayed away from it and using btrfs which works well, except for some RAID limitations.

Fortunately the license Sun applied means any lawsuit would need to attack something much more fundamental, like the very idea of interoperability, as they don't have option to "claw back" any portion of the OpenZFS codebase.

Given that they are currently fighting that an API should be copyrightable, doesn't make me confident that they won't do this.

If they do, GPL is fucked anyway. And not just GPL.

ZFS is not released under GPL, if it is then it won't be a problem. So there is a need for an alternative and BTRFS works well for me, no need of license encumbered ZFS, not sure of others.

My personal reason is that zfs.ko entirely bypasses the kernel page cache, preferring its own internal cache (the ARC). Reimplementing kernel subsystems is a recipe for interoperability nightmare (c.f. the NVIDIA binary driver). For instance, this causes unnecessary memory pressure when you have a mix of ZFS and non-ZFS filesystems (e.g. SMB mounts).

Additionally I curmudgeonly have yet to come to terms with the blatant layering violation of ZFS being a combined block-device-manager and filesystem. But the benefits (file-level RAID behaviour) of that are indeed clear.

> I curmudgeonly have yet to come to terms with the blatant layering violation of ZFS being a combined block-device-manager and filesystem

It has both advantages and disadvantages. It’s a trade-off. ZFS decided it was worth it, and so did btrfs.

Sure they committed these crimes, but those are the reasons why ZFS is better than the alternatives.

Reply on news.ycombinator.com