feat(storage): add zfs-buildkit-{32k,128k,1m} for a fair recordsize comparison #404

Merged

binjovi-bot merged 1 commit from feat/zfs-buildkit-classes into trunk

2026-09-07 12:52:10 +00:00

sean commented

2026-09-07 11:45:41 +00:00

Owner

Three ZFS datasets with identical properties (atime=off sync=disabled primarycache=all), created by one loop, with recordsize set per StorageClass. Nothing else differs.

Why. The BuildKit caches are the heaviest ZFS consumers here and the classes they sit on cannot say which recordsize suits them: zfs-nvme-128k is backed by tank/ephemeral (sync=disabled), zfs-nvme-32k by tank/databases (sync=standard, logbias=latency, primarycache=all), zfs-nvme-1m by tank/bulk (sync=disabled, primarycache=metadata). Each pairs a recordsize with its own durability and ARC policy, so moving a cache between them changes several things at once.

logbias is deliberately unset — the ZIL is unused under sync=disabled, so it would have no effect and would read as a fourth variable.

Purely additive. No existing StorageClass or dataset property changes, and nothing consumes the new classes yet.

Verification. tests/zfs-buildkit-classes.sh pins the invariant that makes the comparison mean anything, and was checked against five mutations (per-class compression change, ARC policy change, logbias reintroduced, a dataset dropped from the loop, a class recordsize no longer matching its dataset) — each detected. The pool-init script was exercised with stubbed zfs/zpool: six datasets created, three properties set identically across the family, the older three untouched, idempotent on a second run. tests/check.sh green.

https://claude.ai/code/session_01KZoQin34jeyt6nDGqvJA76

Three ZFS datasets with **identical** properties (`atime=off sync=disabled primarycache=all`), created by one loop, with `recordsize` set per StorageClass. Nothing else differs. **Why.** The BuildKit caches are the heaviest ZFS consumers here and the classes they sit on cannot say which recordsize suits them: `zfs-nvme-128k` is backed by `tank/ephemeral` (sync=disabled), `zfs-nvme-32k` by `tank/databases` (sync=standard, logbias=latency, primarycache=all), `zfs-nvme-1m` by `tank/bulk` (sync=disabled, primarycache=metadata). Each pairs a recordsize with its own durability and ARC policy, so moving a cache between them changes several things at once. `logbias` is deliberately unset — the ZIL is unused under `sync=disabled`, so it would have no effect and would read as a fourth variable. **Purely additive.** No existing StorageClass or dataset property changes, and nothing consumes the new classes yet. **Verification.** `tests/zfs-buildkit-classes.sh` pins the invariant that makes the comparison mean anything, and was checked against five mutations (per-class compression change, ARC policy change, logbias reintroduced, a dataset dropped from the loop, a class recordsize no longer matching its dataset) — each detected. The pool-init script was exercised with stubbed `zfs`/`zpool`: six datasets created, three properties set identically across the family, the older three untouched, idempotent on a second run. `tests/check.sh` green. https://claude.ai/code/session_01KZoQin34jeyt6nDGqvJA76

sean added 1 commit

2026-09-07 11:45:41 +00:00

feat(storage): add zfs-buildkit-{32k,128k,1m} for a fair recordsize comparison

binjovi/ci Binjovi completed the frozen plan

Details

097b9d9509

The BuildKit caches are the heaviest ZFS consumers here, and the classes they
sit on today cannot say which recordsize suits them. zfs-nvme-128k is backed
by tank/ephemeral (sync=disabled), zfs-nvme-32k by tank/databases
(sync=standard, logbias=latency, primarycache=all) and zfs-nvme-1m by
tank/bulk (sync=disabled, primarycache=metadata). Each pairs a recordsize with
its own durability and ARC policy, so moving a cache between them changes
several things at once and the result cannot be attributed to the blocksize.

This adds three datasets carrying identical properties -- atime=off,
sync=disabled, primarycache=all -- with recordsize set per StorageClass. One
loop creates all three, so they cannot drift apart by editing one of them.

logbias is deliberately unset: the ZIL is unused under sync=disabled, so it
would have no effect and would read as a fourth variable.

Purely additive. No existing StorageClass or dataset property changes, and
nothing consumes the new classes yet.

tests/zfs-buildkit-classes.sh pins the invariant that makes the comparison
mean anything: the three classes may differ in recordsize and in nothing else.
Verified against five mutations -- a per-class compression change, an ARC
policy change, logbias reintroduced, a dataset dropped from the loop, and a
class recordsize that no longer matches its dataset -- each detected.

The pool-init script was exercised with stubbed zfs/zpool: it creates all six
datasets, sets exactly the three intended properties identically on the
buildkit family, leaves the older three untouched, and is idempotent on a
second run.

Claude-Session: https://claude.ai/code/session_01KZoQin34jeyt6nDGqvJA76