# OpenZFS 2.4.4 on Linux 7.3

First working port of OpenZFS 2.4.4 to Linux 7.3, built and proven on
real hardware (pools imported healthy, datasets mounted). Status:
**experimental** — built with `--enable-linux-experimental`, which
prints an honest `EXPERIMENTAL and SERIOUS DATA LOSS may occur` line
at module load. Do not put irreplaceable data behind this yet.

Related: [OpenZFS issue #19032](https://github.com/openzfs/zfs/issues/19032)
(kernel 7.3 support tracking).

## Base

- OpenZFS `zfs-2.4.4.tar.gz` from the 2.4.4 release
  (`sha256 2a3c70d55a37cc71618a95a60e81ad66530201eb118d37741dc92efcf848c8b1`).
- Linux 7.3 stable (`linux-7.3.tar.xz` from kernel.org).
- No kernel source changes needed (see `kernel/NOTES.md`).

## What broke, and why

Linux 7.3 changed four things out from under the 2.4.4 tree, plus
one latent assumption:

1. **`inode_operations->create` dropped the `bool flag` arg**
   (kernel commit `61cb6c7`). The old configure chain (idmap →
   userns → flags → fatal error) can no longer match anything, and
   would abort the build even though the fix is small.
2. **`bvec_iter.bi_bvec_done` renamed to `bi_offset`.**
3. **Kernel threads lost implicit filesystem access.**
   Pool import and taskq work run in kthreads; on 7.3 they must wrap
   filesystem-touching code in `scoped_with_init_fs()`.
4. **`static_cpu_has()` replaced by `cpu_feature_enabled()`.**
5. **The idmap fallback chain assumes pre-7.3.** With none of the
   old `HAVE_IOPS_CREATE_*` macros defined, `zidmap_t` falls back to
   `struct user_namespace` while VFS now demands `struct mnt_idmap`,
   so every idmap call site (`policy.c`, `zfs_acl.c`, …) fails with
   incompatible-pointer-type.

## What we changed (in `patches/`, apply in order)

| File | Origin | Content |
|------|--------|---------|
| `0001-…-bvec-bi-offset` | upstream [`79fc679`](https://github.com/robn/zfs/commit/79fc679547d6) verbatim, blkdev hunk rebased to zero offset | autoconf test + `BIO_BI_SKIP` switch |
| `0002-…-kthread-fs` | upstream [`e8a0a6cd`](https://github.com/robn/zfs/commit/e8a0a6cd4ed3), rebased to 2.4.4 (Makefile.am list, DTRACE-ful `taskq_thread`) | new `kthread_compat.h` (verbatim), both call sites wrapped |
| `0003-…-cpu-feature` | upstream [`844c3a4e`](https://github.com/robn/zfs/commit/844c3a4eb6c1), rebased to 2.4.4 (`HAVE_XSAVES` guards; `_bug` probe untouched) | seven probes swapped |
| `0005-…-inode-create` | upstream [`d01c2c7f`](https://github.com/robn/zfs/commit/d01c2c7fdef8), ported (2.4.4 already ships a `kernel-inode-create.m4` for the 6.3 change, so the test is appended and the decision checks no-flag **first**) | new autoconf test + `zpl_create` 3-arg branch in 2.4.4 spelling |
| `0006-…-idmap-era` | ours (no upstream equivalent; master refactored the fallback away) | `NO_FLAG` joins the mnt_idmap-era checks (`types.h`, `spl-cred.c`, four `cred.h` fast paths), including the shadow-guard fix |

(There is no `0004`: the upstream new-file extract was folded into
`0005` when 2.4.4 turned out to already ship that filename.)

`zfs-2.4.4-linux-7.3-combined.patch` is the same five, concatenated,
for one-shot application: `patch -p1 < zfs-2.4.4-linux-7.3-combined.patch`.
Every hunk applies with zero fuzz and zero offset (verified); any
drift fails closed rather than shipping half-patched sources.

Two build-system notes: patching `config/*.m4` means running
`./autogen.sh` before `./configure` (never trust a shipped
`configure` over patched macros), and configure with
`--enable-linux-experimental` past the 7.2 version gate.

## Relationship to robn/zfs@linux-7.3-compat

That branch did the API analysis we built on (thank you) — but it
targets upstream master, whose tree has drifted past 2.4.4
(`ZPL_IDMAP_IOP_DEFINE`, removed DTRACE probes, new headers), so its
diffs do not apply to the 2.4.4 release. This pack is the same four
fixes plus the idmap-era treatment, backported to the 2.4.4 spelling
and proven by a build, not by inspection.

## Test evidence

- Full `make modules`-style out-of-tree build against a stock 7.3
  tree: clean (modulo the two pre-existing warnings also present on
  older kernels).
- `modprobe zfs` on a 7.3.0 machine: loads v2.4.4-1, EXPERIMENTAL
  line as designed, existing pools import healthy, datasets mount.
- Not yet done: scrub/load soak, `zpool upgrade` (deliberately
  untested — do NOT upgrade pools under this build), production use.

## Suggested upstream path

For `master`: only the idmap-era fallback removal may still be
relevant (master refactored past it — verify rather than port). For
the 2.4.x line, if a 2.4.5 happens: these five patches plus the
experimental flag are the backport, with the test evidence above.

Offered under the same CDDL-1.0 as the tree it patches. Errors are
ours; the analysis debt is robn's branch and issue #19032.