misc-next one-pass port plan

Zygo's ruling (2026-09-17): "Do misc-next in one pass." Not a trickle of catch-up commits -- one deliberate replay that brings the submission lane level with 6.18, once the parked-rbio fix is green.

Where the lanes stand

Measured 2026-09-17 by comparing commit subjects over each topic:

The 39 on misc-next are a strict subject-subset of the 73 on 6.18 -- the comparison finds nothing on misc-next that 6.18 does not also have. So the port is an append, not a merge: no divergent work to reconcile, no commit to drop.

What moves

34 subjects are on 6.18 and not on misc-next. Two of them must NOT be ported; the other 32 do.

Do not port (6.18-only, by design)

1. btrfs: stripe_alloc: refuse space_cache=v1
2. btrfs: stripe_alloc: let the property accept a cache-less filesystem like the mount option does (b72dc2da)

Both exist because 6.18's mount path accepts a cache-less filesystem while misc-next's demands the free space tree outright (super.c, the btrfs_check_mountopts() gate). misc-next is therefore already symmetric between the mount option and the btrfs.stripe_alloc property, which is the property the pair restores on 6.18. Porting them would be a no-op at best. The covers README already records that the lane carries one 6.18-only patch (734c4596).

Port (32)

The ENOSPC/relocation/reclaim chain v2 (landed on 6.18 2026-09-16), the 7 review-round-1 fixes, and the stripe_meta reserve work:

• btrfs: raid56: do not call a covered stripe_meta group uncovered
• btrfs: stripe_alloc: admit data reservations by whole stripes
• btrfs: stripe_alloc: charge relocation a margin per reservation, not per extent
• btrfs: stripe_alloc: charge the held stripe margin against every admission
• btrfs: stripe_alloc: charge the preallocation's stripe hold under the reservation lock
• btrfs: stripe_alloc: count nocow run lifecycles and stranded stripes in sysfs
• btrfs: stripe_alloc: count whole stripes stranded behind live runs as trapped
• btrfs: stripe_alloc: do not count trapped free space twice when making a block group read-only
• btrfs: stripe_alloc: do not read an inline backref off a keyed-ref extent item
• btrfs: stripe_alloc: give a queued stripe group a chunk to relocate into when the supply is short
• btrfs: stripe_alloc: give nocow extents a private run only while they may be written in place
• btrfs: stripe_alloc: hand groups full of trapped free space to the reclaim worker
• btrfs: stripe_alloc: hold a stripe of margin across a preallocation
• btrfs: stripe_alloc: hold the probe margin until the metadata reservation charges it
• btrfs: stripe_alloc: keep the admitted bytes placeable when a group goes read-only
• btrfs: stripe_alloc: keep the relocation group's stripes out of the admission supply
• btrfs: stripe_alloc: let a data write fall back to the relocation group rather than drop
• btrfs: stripe_alloc: never let relocation wait on the whole-stripe gate
• btrfs: stripe_alloc: release open stripe runs when a mount fails or an aborted filesystem unmounts
• btrfs: stripe_alloc: relocate a queued stripe group even while it has reserved or pinned bytes
• btrfs: stripe_alloc: return a group's allocation cluster before scanning its stripes
• btrfs: stripe_alloc: saturate the read-only guard's claimable subtraction
• btrfs: stripe_alloc: show per-group trapped bytes in the space info dump
• btrfs: stripe_alloc: tell a dead tree block from a live one in the metadata RMW audit
• btrfs: stripe_meta: back the global reserve with usable stripes, and say when a tree block finds none
• btrfs: stripe_meta: carry raid56 metadata groups through a runtime enable or disable
• btrfs: stripe_meta: do not steal from the global reserve below the relocation reserve
• btrfs: stripe_meta: hold back whole stripes so tree blocks always land and trapped groups can be reclaimed
• btrfs: stripe_meta: let a group go read-only for relocation against the reserve
• btrfs: stripe_meta: let the transaction machinery's own reservations draw on the reserve
• btrfs: stripe_meta: maintain trapped free space for metadata groups like data
• btrfs: stripe_meta: sync the open-run remainder when the commit retires metadata runs

Fold, do not append

btrfs: stripe_alloc: hold a reference on parked rbios (1459c2b83afb on 6.18) fixes the park machinery, and misc-next already carries the commit that introduces it -- btrfs: raid56: batch stripe_alloc partial writes into full-stripe writes. On a submission lane the bug must never exist between two patches of the same series, so fold it into that commit rather than append it. (On 6.18 it stays a separate commit: that lane is a production branch with a history worth reading.)

The same rule already applied on 6.18 for the mixed-block-group refusal, which was folded into the patch that introduces btrfs_stripe_alloc_check_support().

Checked 2026-09-17: all six of the fix's exact-string anchors match exactly once in misc-next's fs/btrfs/raid56.c. The bug is present on that lane and the edit applies unchanged, so the fold is mechanical -- blobedit.py with the same edits file (parkref-edits.json) against the park commit.

One open decision: the raid6 testing aid

6.18/topics/raid6-fixes carries a second commit as of 2026-09-17, zygo: DO-NOT-UPSTREAM: lib/raid6: raid6_pq.algo= pins gen_syndrome, kept on the topic so the pin the test rigs boot with survives a rebase and dropped before submission (Zygo's call). misc-next has not been given it, on the grounds that it is the submission lane and is build-check only there, so no rig boots it with a pin. Decide at the one-pass whether it belongs on misc-next/topics/raid6-fixes as well; if a misc-next kernel is ever used for raid6 coverage it does, and the driver's preflight will say so out loud either way.

Afterwards

1. Re-make misc-next/testing and replay the zb64 tail (scripts/lane/lanetopic.sh, or candtopic.sh first if it should be built before the refs move).
2. Update the cover letters on zygo-misc-next-zb64: the series count changes from 39, and the README row that says "one 6.18-only patch" stays true (both 6.18-only patches are in the same family, but the README counts patches -- recount it).
3. The balance-resume cover (e1e3534f) stays a separate cover letter, per Zygo's ruling that its directed test not be bundled with stripe-alloc.

Caveat

The subject comparison is an oracle for what moves, not for whether it applies. misc-next sits on a newer base (kdave 7c6b5acf, 2026-09-16) and 6.18 is hand-adapted to v6.18.x, so 12 of 34 files already hash differently between the lanes (see [stripe-alloc lane drift]). Expect real conflict resolution in the replay, and check the content oracle per topic before trusting the result.