FreeBSD ZFS migrating to ZoL (ZoF)

[Joel]

Heard about this on the reddit Datahoarder thread; just in case you guys haven't heard I thought I'd post it here.

FreeBSD plans to rebase its ZFS implementation on ZoL (ZFS-on-Linux) : linux

TL;DR: FreeBSD ZFS implementation is based on Illumos OpenZFS which is no longer maintained, so future BSD ZFS updates will use the same codebase as ZoL.

For now it seems to me that the legacy BSD flavor is more stable (though I've had no complaints about ZFS on Proxmox), but once migration is complete there will no longer be a significant difference between "ZoF" (ZFS on FreeBSD) and ZoL. They will be sharing a mostly identical codebase.

 

[Patrick]

This makes a lot of sense to me. ZoL has more development. Linux has bigger market share.

For FreeBSD it is good from functionality perspective to align. From a distro perspective it now loses a differentiator

 

[zxv]

Here is the announcement they are talking about:
The future of ZFS in FreeBSD

According to Matthew Ahrens, in a follow up:
"OpenZFS will continue to be an umbrella project for coordinating all work on open-source ZFS." ... "Looking forward, we see more features originating in ZoL. The OpenZFS community (including FreeBSD) is working to put in place technical processes to ensure that new ZFS features are available on all platform."

Joyent and Nexenta are actively contributing to Illumos, and there are downstream open source distros, such as omniosce.

 

[gea]

It's all about new ZFS features.
In the last years they were mainly developed from Illumos related firms like Delphix, Joyent or Nexenta where most ZFS developers landed when they left Oracle after overtaking Sun.

The common Open-ZFS platform ensures that new features could be part of ZFS in Free-BSD or ZoL

Now the situation is different.
The Linux platform is much much larger than the Unix variants Free-BSD or Solarish. ZFS is now also the leading filesystem on Linux with many firms developing around ZFS.

A typical example is ZFS encryption. While it is based on the OpenSolaris/Illumos bits where it was nearly ready (Oracle published it with Solaris 11) and not Linux to avoid GPL problems, it is finalized by Datto on ZoL and is now in the process of beeing ported to Illumos and Free-BSD.

Porting it to Illumos and then from Illumos to Free-BSD makes no sense. Porting form the OS of origin to a target OS is always needed and should be done directly.

OS of origin of new ZFS features is more and more ZoL and to a lesser extend Illumos.
After all this is good news for ZFS on all platforms and this means today Free-BSD, Illumos, OSX, propably Windows and Linux.

Up to now new ZFS features were mostly available first on Illumos and with a delay on others. Whats happening is that more and more are first published on ZoL and with a delay on the others.

 

[i386]

Joyent and Nexenta are actively contributing to Illumos

That's correct, but illumos is more than just zfs and the vast majority of commits for the zfs code came from delphix (and the zol project).

 

[Joel]

It's all about new ZFS features.

My understanding is the only major feature present in Illumos ZFS that is lacking in ZoL is TRIM support.

I agree with the sentiment that overall it's a good thing for ZFS, although BSD itself may become even more marginalized than it is today.

 

[zxv]

I'm using both, and there are lots of tradeoffs either direction.

On ZoL, you can't set sharesmb=name=sharename.
Instead, the shares are poolname_datasetname.

I was in the habit of using data set name only as the smb share name. That allows migrating the data set between pools as needed, but can't be done on ZoL.

The worst problem for me is the impact of Linux's differing unmount feature vs Illumos or freebsd. On ZoL if a dataset is exported as nfs or smb, unmount generally fails. If a remote host has a file open, the only way I've been able to force an unmount is to stop the nfs and/or smb server first. Sometimes only reboot can force it.

The features differ in practice. I hope the plan for convergence between the ports will eventually smooth some of these out as well.

 

[gea]

The SMB differences are not related to ZFS as a filesystem but related to the SMB server or the OS. On Solarish you mostly use the ZFS/OS embedded SMB server that offers these features.

If you use SAMBA the situation is different.
SAMBA itself does not care about ZFS and not not every behaviour of the kernelbased SMB server can be simulated. This affects share settings, ACL and snaps as previous versions

 

[CJRoss]

Interesting. Hopefully this will lead to faster progress on the ZFS wishlist.

 

[zxv]

The SMB differences are not related to ZFS as a filesystem but related to the SMB server or the OS. On Solarish you mostly use the ZFS/OS embedded SMB server that offers these features.

If you use SAMBA the situation is different.
SAMBA itself does not care about ZFS and not not every behaviour of the kernelbased SMB server can be simulated. This affects share settings, ACL and snaps as previous versions

Here's some additional info about the share name issue in ZoL.
Cannot set SMB share name (eg. sharesmb=name=incoming) · Issue #7983 · zfsonlinux/zfs

Here's additional info about the unmount issue.
It affects zpool export and zpool destroy as a result.
export -f : pool busy · Issue #6855 · zfsonlinux/zfs
zfs destroy : device is busy and dataset is busy. · Issue #5327 · zfsonlinux/zfs

This is due in part to the differing linux kernel unmount(). When forcing an unmount() linux may fail with EBUSY rather than forcing unmount, which illumos and freebsd can do.

 

[zxv]

Here are tables showing the progress porting various ZFS features between illumos, freebsd, linux and OSX:
Features - OpenZFS

There are certain features, such as TRIM support for SSD which has not yet been merged into ZoL.

I'm not trying to say either one is better, but rather point out how the trade-offs can vary, and can depend on use case.