On 15 January 2019 the Linux kernel mailing list was discussing a small patch for Linux 5.0. It stopped exporting two functions, __kernel_fpu_begin() and __kernel_fpu_end(), through which code in a kernel module may borrow the processor's SIMD registers, which let one instruction work on several values at once. The kernel no longer used them outside its own files. One project outside the kernel used them a great deal: ZFS on Linux computed its checksums and its RAID-Z parity with them.
A user protested on the list. Greg Kroah-Hartman, who maintains the stable kernels, answered that ZFS "could be the best filesystem ever to grace this planet, that's fantastic", but that its creators had chosen a licence "specifically designed to not be compatible with Linux", and so: "you can see why I really don't care about it. Why would I?" Christoph Hellwig, a long-standing kernel developer, was briefer. He told the user to "please switch to FreeBSD instead of advocating to violate the copyright and licensing rule on my and others work."
The habit
ZFS on Linux is no fringe arrangement. Debian carries it in its contrib section, and Ubuntu has shipped the module with its kernel since 16.04 in 2016. Proxmox VE has offered ZFS since 3.4, as a root filesystem too, with everything precompiled; its own documentation says there is "no need for manually compile ZFS modules". TrueNAS, whose storage appliance grew up on FreeBSD, moved its FreeBSD edition into sustaining engineering in 2024 and has run its unified product on Linux 6.12 since release 25.04. Linux brings the larger hardware support and the larger ecosystem, and on both systems the filesystem itself is the same OpenZFS code.
That is the habit at its strongest. What it leaves out is who carries the arrangement, and for how long.
What the kernel says about it
The Linux kernel is licensed under GPLv2 and OpenZFS under Sun's CDDL, and in the reading of the Free Software Foundation and the Software Freedom Conservancy the two may not be combined in a distributed binary. Debian follows that reading. It ships zfs-dkms, version 2.3.9 in Debian 13, as source code in its contrib section, and the module is compiled on the administrator's own machine, once at installation and again after every kernel update. Canonical reads the licences the other way and ships the binary, which the Software Freedom Conservancy described in 2016 as an "ongoing violation by Canonical". No court has decided between them.
The kernel developers took the licence at its word, and they owe the module nothing. The patch from that January thread went into Linux 5.0 in March 2019, and ZFS on Linux lost the vector code behind its Fletcher-4 checksums and its RAID-Z parity; the encryption code went scalar along with them. It got them back in July 2019 by saving and restoring the registers itself (OpenZFS pull request 8965, merged on 12 July). A year later, on 6 January 2020, Linus Torvalds set out the position in full on the Real World Technologies forum: "If somebody adds a kernel module like ZFS, they are on their own. I can't maintain it, and I can not be bound by other peoples kernel changes." A few lines further down he reached his conclusion: "Don't use ZFS. It's that simple."
In the same post he wrote that ZFS had "no real maintenance behind it either any more". OpenZFS has published 56 stable releases since that day, across five new major versions from 2.0 to 2.4.
What a kernel update does
On Debian, zfs-dkms registers the module with DKMS, and every new kernel package sets off a build. The source in question is not small: the module directories of OpenZFS 2.3.9, as Debian ships them, hold 368,777 lines of C and assembly in 399 files, headers and comments included, counted on 6 October 2026. All of it is compiled on the server against the headers of the new kernel, with whatever compiler happens to be installed there. When the OpenZFS version does not yet support that kernel, the build fails and the new kernel arrives without ZFS, which on a machine whose root lives on ZFS means choosing the old kernel at the boot prompt. Debian and Ubuntu keep their stable kernels on long-term branches, and Proxmox ships kernels it has tested with the module, both for exactly this sort of reason.
Boot environments exist on Linux too, through ZFSBootMenu and zectl, two separate projects installed and maintained on their own schedules.
The window
"On their own" has a measurable shape. Every new Linux kernel needs a ZFS module adapted to it, and until an OpenZFS release supports that kernel, a machine that keeps its root filesystem on ZFS has to hold the new kernel back. I compared the last seventeen mainline kernels with the first stable OpenZFS release whose notes declare support for each, counted on 6 October 2026 from the kernel's tags and the OpenZFS releases on GitHub:
kernel released first OpenZFS supporting it days
6.6 30 Oct 2023 2.2.1 22 Nov 2023 23
6.7 07 Jan 2024 2.2.3 22 Feb 2024 46
6.8 10 Mar 2024 2.2.4 02 May 2024 53
6.9 12 May 2024 2.2.5 06 Aug 2024 86
6.10 14 Jul 2024 2.2.6 04 Sep 2024 52
6.11 15 Sep 2024 2.2.7 12 Dec 2024 88
6.12 17 Nov 2024 2.2.7 12 Dec 2024 25
6.13 19 Jan 2025 2.3.1 10 Mar 2025 50
6.14 24 Mar 2025 2.3.2 01 May 2025 38
6.15 25 May 2025 2.2.8 12 Jun 2025 18
6.16 27 Jul 2025 2.3.4 25 Aug 2025 29
6.17 28 Sep 2025 2.3.5 18 Nov 2025 51
6.18 30 Nov 2025 2.4.0 18 Dec 2025 18
6.19 08 Feb 2026 2.4.1 25 Feb 2026 17
7.0 12 Apr 2026 2.4.2 12 May 2026 30
7.1 14 Jun 2026 2.4.4 21 Aug 2026 68
7.2 16 Aug 2026 2.4.4 21 Aug 2026 5The window ran from five days to eighty-eight, with a median of thirty-eight. For five weeks after a typical kernel release, the newest Linux and the newest released ZFS did not fit together, and every distribution offering both had to decide on its own how to bridge the gap. Twice a single ZFS release closed two windows at once, 2.2.7 for 6.11 and 6.12 in December 2024 and 2.4.4 for 7.1 and 7.2 in August 2026, which is why the shortest wait in the table follows directly on one of the longest.
The same job on FreeBSD
On FreeBSD 15.1 the installer puts "Auto (ZFS)" at the top of its partitioning menu on amd64, arm64, i386 and RISC-V. ZFS arrived in FreeBSD 7.0 in February 2008, marked experimental, and it has been part of the base system ever since. With 13.0 in April 2021 the project moved to OpenZFS as its upstream, which is the very code Debian users compile through DKMS, and the module comes out of the same release process as the kernel. The machine I checked this morning (it also serves this blog) runs FreeBSD 15.1-RELEASE-p3 and reports zfs-kmod-2.4.2, the OpenZFS release of May 2026.
On FreeBSD that window does not exist, because ZFS has no release schedule of its own to wait for. Kernel and ZFS leave the project in one release and are patched together by freebsd-update, which since 12.3 and 13.1 takes a boot environment before it installs anything; bectl, in the base system since 12.0, lists those environments and boots the previous one when a new one disappoints. The idea came from Solaris, and on FreeBSD it began in 2012 as vermaden's beadm, a shell script in the ports. Checking and rolling back take a handful of commands, all of them shipped with the system:
% sysctl vfs.zfs.version.module
vfs.zfs.version.module: 2.4.2-1
# freebsd-update fetch install
# shutdown -r now
# bectl list
# bectl activate <the environment from before the update>
# shutdown -r nowNothing is compiled on the server, and nothing waits for another project to catch up. Both systems need glue between ZFS and their kernel, and the OpenZFS tree carries both: in the same 2.3.9 source, 41,456 lines for Linux under module/os/linux and 31,690 for FreeBSD under module/os/freebsd. The difference lies in where the glue is built. On FreeBSD it sits in the base tree and is compiled by the project together with the kernel it belongs to. On Linux it is compiled on the customer's machine, against a kernel whose maintainers have said they will not take it into account. The licence question does not arise either: the CDDL code sits in the FreeBSD tree under sys/contrib/openzfs, next to the BSD code, and the project ships the binary.
Who carries the integration
Every Linux distribution that offers ZFS has built the integration for itself. Debian leaves the compiling to the administrator. Ubuntu ships the binary and the legal argument with it. Proxmox builds and tests its own kernel with the module inside, and TrueNAS pins a long-term kernel and ships its own build. Each of them solves the same problem separately, and each carries the window and the licence question on its own account.
In the terms of my book, Integrated by Design, ZFS shows the two models in a single case: the integrated system solved the problem once, in 2008, and the assembled one has been solving it again in every distribution that wants the feature, with the kernel's own maintainers on record that they will not help.
The limit
Four limits, stated plainly.
The filesystem is the same. FreeBSD and Linux run the same OpenZFS code, and nothing in this piece makes ZFS faster or more capable on FreeBSD.
The window rarely opens on Debian stable or Ubuntu LTS, whose kernels move slowly. It opens on rolling distributions and wherever new hardware or a backported kernel moves the kernel ahead of ZFS.
Linux brings the larger hardware support and the larger application ecosystem. It is part of why TrueNAS, which sponsored FreeBSD's move to OpenZFS in 13.0, moved its own product to Linux.
The licence question is unsettled. Canonical considers the shipped module lawful, and no court has ruled.
On FreeBSD, ZFS is simply part of the system: offered first by the installer, released with the kernel, patched by freebsd-update and rolled back by bectl. Christoph Hellwig offered his advice as a dismissal, and as a recommendation it has aged rather well.
In January 2019 a Linux kernel developer told a ZFS user to switch to FreeBSD. On Debian every kernel update still compiles 368,777 lines of ZFS on the server, and across seventeen kernels the newest one waited 38 days at the median for a ZFS release that supports it. On FreeBSD, ZFS has left the project in the same release as the kernel since 2008, with a boot environment taken before every update.