ZFS Indications Have Us Already Eager For Ubuntu 19.10

[phoronix]

Phoronix: ZFS Indications Have Us Already Eager For Ubuntu 19.10

While Ubuntu 19.04 isn't even coming out until tomorrow, the indications around Ubuntu desktop ZFS support and functionality likely debuting the next cycle has us already quite eager for the Ubuntu 19.10 release coming out in October...

http://www.phoronix.com/scan.php?page=news_item&px=ZFS-GRUB-More-Bits-April-Ubuntu

[gorgone]

i hope it uses ZOL 0.8 .... than we have ssd trim support ootb ... and maybe a easy port to debian/proxmox

[Min1123]

I was a big fan of ZOL, until I got tired of dealing with new kernel incompatibilites from using it under Fedora, and I decided to use FreeBSD for my NAS instead. Seems ZOL sets a filesystem flag that is specific to Linux, and thus the zpools made with, or upgraded under, ZOL cannot be opened read-write, and must be manually opened read-only under any non-ZOL ZFS implementation.

I'm gonna check for that (in a VM) before any future usage of ZOL.

[mskarbek]

i hope it uses ZOL 0.8 .... than we have ssd trim support ootb ... and maybe a easy port to debian/proxmox

For sure not. IMO 0.8.0 will not be ready until 19.10 release so they have to work with 0.7.13.

[mskarbek]

I was a big fan of ZOL, until I got tired of dealing with new kernel incompatibilities from using it under Fedora, and I decided to use FreeBSD for my NAS instead. Seems ZOL sets a filesystem flag that is specific to Linux, and thus the zpools made with, or upgraded under, ZOL cannot be opened read-write, and must be manually opened read-only under any non-ZOL ZFS implementation.

I'm gonna check for that (in a VM) before any future usage of ZOL.

If you enable all the features available in ZoL then yes, you will have a problem with using such pool under Illumos/FreeBSD. There is a proposal to deal with that by initially creating a pool with enabled only features available in every implementation not all of them.
I term of kernel compatibility there is no problem on Fedora, you just can't assume that you will be able to update to the newest available in the repository right after its release. I'm still on the 4.19.15.fc29 with kernel packages excluded in repo config. ZoL team doesn't have the capacity to release new package every time kernel folks change something, if you really need to have newest (currently in the repo that would be 5.0.7) kernel then ZoL is not the best choice.

[starshipeleven]

Seems ZOL sets a filesystem flag that is specific to Linux, and thus the zpools made with, or upgraded under, ZOL cannot be opened read-write,

More like ZoL by default creates a filesystem with all features enabled and ZoL supports features that ZFS on BSD does not.

This problem should solve itself in a year or so, since FreeBSD (and FreeNAS) are switching to ZoL codebase, so they will support the same features.

[jrch2k8]

I was a big fan of ZOL, until I got tired of dealing with new kernel incompatibilities from using it under Fedora, and I decided to use FreeBSD for my NAS instead. Seems ZOL sets a filesystem flag that is specific to Linux, and thus the zpools made with, or upgraded under, ZOL cannot be opened read-write, and must be manually opened read-only under any non-ZOL ZFS implementation.

I'm gonna check for that (in a VM) before any future usage of ZOL.

FreeBSD and Illumos use features defined as Version 5000 that was the last set of features from the old SUN days and opensolaris, ZoL on the other hand have extra features like large dnodes, lz4 compression, TRIMM, etc. that neither FreeBSD nor Illumos current ZFS implementations understand, your best bet is to recreate the pools passing an specific version flag to retain compatibility.

If you want the best experience on ZOL+ Linux your best bet right now is ArchLinux with archzfs repo, since is usually couple day behind new kernels top and pacman is smart to block kernel updates until archzfs repo is up to date.

For those few hours you may have to wait between repo syncs just use

pacman -Syu --ignore=linux to upgrade the rest of your system

[Min1123]

OK, I suppose I should have specified, I just didn't want to go look it up.

org.zfsonlinux:userobj_accounting

This is only on ZOL (currently), is put in by default on new volumes made with ZOL, and is incompatible with the current non-ZOL implementations, meaning that FSes made with ZOL are not universal.

Also, yes, I'm upset because it killed a weekend doing a migration from ZFS and back to ZFS so I could move to something more stable.

[Chugworth]

OK, I suppose I should have specified, I just didn't want to go look it up.

org.zfsonlinux:userobj_accounting

This is only on ZOL (currently), is put in by default on new volumes made with ZOL, and is incompatible with the current non-ZOL implementations, meaning that FSes made with ZOL are not universal.

Also, yes, I'm upset because it killed a weekend doing a migration from ZFS and back to ZFS so I could move to something more stable.

Just a few weeks ago I transferred several ZFS datasets from Ubuntu 18.04 to FreeNAS using "zfs send". I did notice that their storage usage was a bit more on FreeNAS, but other than that the datasets worked fine.

[itoffshore]

I was a big fan of ZOL, until I got tired of dealing with new kernel incompatibilites from using it under Fedora, and I decided to use FreeBSD for my NAS instead. Seems ZOL sets a filesystem flag that is specific to Linux, and thus the zpools made with, or upgraded under, ZOL cannot be opened read-write, and must be manually opened read-only under any non-ZOL ZFS implementation.

I'm gonna check for that (in a VM) before any future usage of ZOL.

I've not had any problems running Manjaro with linux-hardened & zfs-dkms-git - this avoids kernel incompatibilities & gives me native encryption.