OpenZFS 2.4.4 was released on Friday, August twenty first, 2026, and the change most likely to save someone a bad afternoon is a new zhack mmp reclaim command. It recovers a pool left stranded by Multi Modifier Protection, the mechanism that stops two hosts importing the same pool and destroying it. The release also adds Linux 7.2 support, taking the supported kernel range to 4.18 through 7.2, and makes systemd-udev-settle optional for the import units. Several real bugs close underneath: an infinite loop in zfs_write, mmap reads past end of file, and fallocate failing to update timestamps when it grows a file.
The short answer
OpenZFS 2.4.4 shipped on Friday, August twenty first, 2026. A new zhack mmp reclaim command recovers pools stranded by Multi Modifier Protection. Linux 7.2 support lands via a conversion to the kernel's sget_fc() interface, taking the supported range to 4.18 through 7.2, and systemd-udev-settle becomes optional for the import units. Fixes cover an infinite loop in zfs_write, mmap reads past end of file, and fallocate timestamps. OpenZFS 2.3.9 and 2.2.11 shipped alongside with backports.
Point releases of a filesystem are usually a kernel compatibility bump and a list of fixes nobody reads. This one carries a recovery command, and recovery commands are worth knowing about before you need them rather than during.
The failure MMP is designed to cause
Multi Modifier Protection exists to prevent the single worst thing that can happen to a shared pool: two hosts importing it simultaneously and writing over each other. The importing host stamps a heartbeat into the pool's uberblocks. Any other host that tries to import sees a live heartbeat and refuses.
The mechanism works. The problem is what happens when the heartbeat outlives its author. A node panics mid write. A storage path drops at exactly the wrong moment. The pool is left carrying MMP state asserting that someone owns it, and that someone no longer exists.
From there, every import attempt is refused. The refusal is correct by the rules and completely unhelpful to the person holding the pager, and until now the ways out were a forced import with the risk that entails, or improvised low level surgery.
What the new command gives you
OpenZFS 2.4.4 adds zhack mmp reclaim, which clears the stale MMP state so the pool can be imported normally.
zhack is the low level pool manipulation tool, and putting the recovery there is the right call. It signals what the operation actually is: an explicit assertion by an operator that the previous owner is definitively gone. It is not something an init script should reach for.
The important part is the order, and it is not negotiable. Confirm the other host is down. Not unreachable from your terminal, not failing to answer a ping, but fenced and confirmed. MMP is the thing standing between you and a dual import, and clearing it manually removes that protection for the import that follows.
In a clustered setup this means going through the cluster manager rather than around it, however tempting the shortcut looks at the point where you are already running low level pool surgery. The command makes recovery possible. It does not make verification optional.
Kernel support and boot time
Linux 7.2 support arrives here, taking the officially supported range to 4.18 through 7.2. The main compatibility work was converting the ZFS superblock code to the kernel's sget_fc() interface, part of mainline's long running filesystem context conversion. FreeBSD support continues for 13.3 and later and 14.0 and later.
The change more people will notice is that systemd-udev-settle is now optional for the import units. That dependency forced an unconditional wait for udev to finish processing every device before pools would import. On a system with a handful of disks it is invisible. On a system with a large enclosure it is a measurable chunk of boot time spent waiting for device processing that has nothing to do with the pool you are importing.
The fixes that will bite quietly
Three Linux fixes stand out because of how they present rather than how they read.
An infinite loop in zfs_write() on an unfaultable buffer is fixed. That defect surfaces as a process wedged forever with no useful error anywhere, which is among the least pleasant things to diagnose on a storage server.
Reads through mmap() beyond the end of a file now behave correctly, and fallocate() now updates modification and change timestamps when it grows a file. The timestamp one looks cosmetic and is not. Backup tools, build systems and synchronisation agents decide whether to do work by comparing timestamps, and a file that grew without its mtime moving is a file that quietly does not get backed up.
There are also deduplication table fixes covering negative time overflows, pruning bugs and reference count issues, and a new send:encrypted delegation permission giving finer grained control over operations on encrypted datasets.
Upgrade guidance
If you run OpenZFS on a 7.2 kernel, or expect to soon, this is the release that supports you. If you are on an older branch, OpenZFS 2.3.9 and 2.2.11 shipped the same day with backported fixes, so there is a path that does not require moving branches.
For everyone else the honest answer is that this is a normal point release and normal point release rules apply. Upgrade on your usual schedule. The one thing worth doing today, whether or not you upgrade, is reading the MMP recovery procedure while nothing is broken, because the moment you actually need zhack mmp reclaim is the worst possible moment to be learning what it does.
Sources and further reading
- OpenZFS 2.4.4 Released With Linux 7.2 Support, Dozens Of Fixes, Phoronix, August 21, 2026
- OpenZFS 2.4.4 Adds Linux Kernel 7.2 Support, New MMP Recovery Tool, Linuxiac, August 2026
- OpenZFS 2.4.4 release notes, GitHub
Frequently asked questions
What is MMP and how does a pool get stranded by it?
Multi Modifier Protection is the ZFS safeguard against two hosts importing the same pool at once, which would corrupt it. The importing host writes a heartbeat into the pool's uberblocks, and any other host attempting an import sees that heartbeat and refuses. The failure mode is that the heartbeat outlives the host that wrote it. A node dies mid write, or a shared storage path breaks at the wrong moment, and the pool carries an MMP state that says someone still owns it while nobody does. Every subsequent import is refused, correctly according to the rules and uselessly according to you.
What does zhack mmp reclaim do about it?
It clears the stale MMP state so the pool can be imported again. zhack is the OpenZFS low level pool surgery tool, and the reclaim subcommand is a deliberate, explicit way to say that the previous owner really is gone. Before this release the routes out of that situation were forced imports with the risks they carry, or manual intervention with tools that were never meant for the job. Having a named command means the recovery path is documented and reviewed rather than improvised from a mailing list thread at three in the morning.
When should I absolutely not run it?
When you have not verified that no other host has the pool imported. The entire purpose of MMP is to prevent a dual import, and clearing the state manually removes that protection for the import that follows. If the other node is merely unreachable from where you are standing rather than confirmed down, you do not have the information you need. Fence the other node, confirm it is fenced, then reclaim. In a clustered configuration that means going through the cluster manager rather than around it. The command makes the recovery possible, it does not make the verification unnecessary.
What changed for Linux kernel support?
OpenZFS 2.4.4 adds support for the Linux 7.2 stable kernel, so the officially supported range is now 4.18 through 7.2. The main compatibility work was converting the ZFS superblock code to the kernel's sget_fc() interface, part of the ongoing filesystem context conversion in mainline. FreeBSD support continues for 13.3 and later and 14.0 and later. The release also makes the systemd-udev-settle dependency optional for the import units, which removes an unconditional wait for device processing to finish before pools import, and that wait can be a meaningful chunk of boot time on systems with many devices.
Which bug fixes matter most in day to day operation?
Three stand out on Linux. An infinite loop in zfs_write() that could trigger on an unfaultable buffer is fixed, which is the kind of defect that presents as a hung process nobody can explain. Reads through mmap() beyond the end of a file now behave correctly. And fallocate() now updates modification and change timestamps when it grows a file, which sounds cosmetic until a backup tool or a build system decides nothing changed because the timestamp says so. There are also deduplication table fixes covering negative time overflows, pruning bugs and reference count issues, plus a new send:encrypted delegation permission.