Comment by E39M5S62 | Hacker News Reader

Comment by E39M5S62 | Hacker News Reader

This is a good thing for ZFS and public perception of ZFS. Ubuntu has made some very poor choices with how they've integrated ZFS -

* zsys has both implementation and design flaws. They utilize two zpools - one with limited feature flags that GRUB can use and one general pool, and then try to tightly couple datasets between those two pools while coordinating snapshots. zsys routinely runs a system out of space due to not cleaning up snapshots. It's been known to destroy user data as well.

https://github.com/ubuntu/zsys/issues/196

https://github.com/ubuntu/zsys/issues/218

* Their packaging was and is still very sloppy. It's quite common to catch people running one version of kernel modules and another version of userland tools - often multiple releases apart. This has led to some serious problems.

(no direct source for this, typically noted in libera.chat#zfsonlinux)

* Ubuntu has created and applied bad patches to ZFS, resulting in destroyed pools.

https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/190...

If your exposure to ZFS is through Ubuntu and zsys, you'd naturally have a very poor opinion of it. ZFS, of course, isn't with out flaws. Ubuntu is not helping.

This right here.

As a long time ZFS user, I was excited when Canonical promised first class ZFS integration. But it was clear from the first release that Ubuntu's ZFS project was a mess. Clearly some folks got excited about ZFS, but didn't absorb much of the existing knowledge or wisdom in the ecosystem. Issues like dataset/pool layout, how snapshots were handled on update, were handled in completely unusual and boneheaded ways.

The ecosystem already had the concept of boot environments, which more or less standardized what a rool-on-zpool layout ought to look like, and how to handle graceful, recoverable system upgrades. What Ubuntu could have brought to the table was a really high quality beadm replacement for Linux, moving Grub's ZFS support forward with support for more feature flags and boot environments, or investing in ZFSBootMenu.

Instead they went ahead with zsys, and it's still not entirely clear what they want or expect it to be. That they needed to write a daemon to enable "complex zfs dataset layouts" should've been an early clue that they were going down the wrong path. The dataset layout for a root filesystem should never be so complex, that you need to write a whole daemon to manage it.

The packaging issues and bad patches are almost besides the point.

I don't think they really need the two pool model, booting off efi(fat32) can load the modules, and importing the pool can be handled by the initrd. At least that's how I've been doing it on gentoo for years.

Edit: handcuffing yourself to grub seems pointless. Not to mention, grub is controlled by oracle devs who want nothing to do with zfs support and have actively ignored bringing the grub zfs in line with openzfs mainline.

For sure don't need a limited boot pool. Take a look at https://zfsbootmenu.org - we do it with a single EFI application.

This sounds cool, but it would take a fair amount of changes for me to use it, since I bake the cmdline into the kernel and boot the kernel directly from the efistub. Maybe I'll check it out some day though.

Reply on news.ycombinator.com