docs: TrueNAS 26 is supported; record what has actually been run
CI / python 3.12 (push) Failing after 16s
CI / shell (shellcheck + syntax) (push) Successful in 10s
CI / python 3.11 (push) Failing after 12s
CI / python 3.13 (push) Failing after 16s
TrueNAS compatibility / compat (push) Successful in 9s

The README and how-it-works still said "TrueNAS 26: nested snapshots are not supported
yet" and "the third is not fixed, and is why 26 reports BROKEN". Both shipped in v0.7.0
and are now false — exactly the kind of stale claim that misleads somebody deciding
whether to trust this with their backups.

Adds docs/verification.md: what has ACTUALLY been run, as opposed to what the support
matrix proves. The matrix is static analysis — it shows the patch's assumptions still
hold, which is a strictly weaker claim than "a backup ran and a restore came back". The
new file records the three live tasks exercised on 25.10.4 (nested, nested+zvols,
non-nested), the md5 of the file that came back out of B2, the real orphan the collector
reclaimed from the pool, and what is NOT covered (24.10/25.04 unrun; master broken; no
reboot on v0.7.0). The README now points at it, next to the matrix it qualifies.

The how-it-works TrueNAS 26 section now explains the part that mattered: the public
pool.* queries are not like-for-like replacements for the deleted private zfs.* ones —
they apply a visibility policy hiding 84 of 270 datasets on a real pool, including live
app data — and the rule the module now follows (read the truth from ZFS, make changes
through middleware). Plus the divergence nothing warned about: 26 decides `recursive` by
a different rule than this patch decides `nested`, which orphaned one snapshot per zvol
on every run until ownership of the sweep was made unconditional.
This commit is contained in:
2026-07-14 02:22:36 +00:00
parent 30b9f18166
commit ca906f5ee4
4 changed files with 170 additions and 29 deletions
+8 -3
View File
@@ -941,10 +941,15 @@ def is_broken(r: dict) -> bool:
#: is static analysis of iX's source, which proves the patch's assumptions hold --
#: a strictly weaker claim than "a restore worked". Add a row only after doing it.
HARDWARE_VERIFIED = {
"25.10.4": "nested + providers; 252-snapshot recursive backup of /mnt/Tap, 18m",
"25.10.4": (
"v0.7.0: 3 live tasks — 191-dataset nested backup of /mnt/Tap, a "
"215-filesystem/2-zvol backup of /mnt/Tank/backups, and a non-nested one; "
"0 orphans, 0 leaked mounts, byte-identical restore; the collector also "
"reclaimed a real orphan the pool had been carrying"
),
"26.0.0-BETA.1": (
"nested + providers; 274-snapshot recursive backup of a 292-dataset pool, "
"restored a 4-deep child dataset byte-identical"
"v0.7.0: 274-snapshot recursive backup of a 292-dataset pool; restored a "
"4-deep child dataset byte-identical; zvol-orphan case reproduced then closed"
),
}