OpenZFS 2.4.4 adds a recovery operation for a specific multihost mirror failure and documents Linux compatibility through 7.2. The recovery does more than clear a stale marker: it changes the state of unreachable mirror members after a controlled import.
The stranded mirror case
The 2.4.4 release notes link to the recovery change. Its motivating topology has mirror legs attached to different hosts. If one host fails together with its disks, the surviving configuration can still expect writes to those now-unreachable legs. The multihost claim then cannot collect all required successful writes.
This is different from merely finding an old heartbeat. It is also different from a general repair of missing data or every RAIDZ failure. A refusal to import must be understood before choosing a recovery operation.
What the command changes
The manual in the 2.4.4 tag describes zhack mmp reclaim as a one-time import with the required write count relaxed for mirror legs this host cannot open. It marks those leaves offline and exports the pool again. A subsequent ordinary import is degraded, with those members still offline.
The activity check's writes, wait and reread remain. The operation does not simply disable all multihost protection. A competing importer sharing visible storage can still be detected.
However, a live peer with completely disjoint disk visibility cannot be detected through storage this host cannot reach. The failed peer must be fenced or otherwise proven powered off before recovery. Failed ping or lost SSH access alone does not establish that it has stopped writing.
An original two-host illustration
Imagine a mirror with leg A visible locally and leg B attached to a failed peer. The configuration still expects both. Ordinary claim: two expected writes, only the local leg reachable. After the peer has been fenced, the recovery can mark unreachable B offline and leave the pool exported. The next import uses the resulting degraded configuration.
The diagram depicts that narrow state transition. It is not a command transcript or a claim that PeopleAreGeek recovered a real pool. The manual also documents a limit: a leaf containing the only copy of some data cannot be offlined this way, so the tool can report failure rather than produce a usable recovery.
Upgrade compatibility is a separate decision
The release documents Linux 4.18-7.2 support and fixes including an infinite write loop and mmap reads beyond file size. Installing a compatible package does not demonstrate that a particular pool needs reclaim, nor does it automatically require enabling new pool feature flags.
Keep the distribution's kernel-module and user-space packages aligned, retain a working boot path, and follow the versioned recovery documentation for the actual topology. This article explains when the new operation applies; it is not an invitation to run it as a routine import shortcut.
Correct reclaim mechanics against the tagged manual: mirror-leg write claim relaxation, offline marking and export, with fencing and retained activity checks.