bcachefs: swap file support via SWP_FS_OPS

[Komzpa]

References koverstreet/bcachefs#368, duplicate report koverstreet/bcachefs#923, and the earlier draft koverstreet/bcachefs#1072. Companion ktest coverage is in koverstreet/ktest#63.

This ports Matthias Goergens' SWP_FS_OPS swapfile support to current bcachefs-tools/testing, preserving the original author and keeping the branch focused on the swap implementation.

Compared with the old draft, this version deliberately drops:

• duplicate SRCU-audit and investigation/VM harness files
• hardcoded module/version/debug load markers
• the debug-build BUG_ON path in swap I/O
• the bch2_swap_noreclaim_enabled boot toggle and hot-path global check
• broad write-buffer PF_MEMALLOC changes outside swap
• the extents leaf-fill debug logging

This revision also narrows alloc-btree pinning: instead of pinning BTREE_ID_alloc from POS_MIN to SPOS_MAX, swap activation now walks the swap file extents and pins the alloc-btree bucket ranges reached by direct extent pointers. Non-direct extent types are rejected during activation for now rather than silently under-pinning them; reflink/indirect support can be added once the desired policy is clear.

The latest update tightens swapon cleanup paths: failed disk reservation now unpins btree nodes, failed add_swap_extent() unwinds the actual btree reserve and disk reservation, and swapoff removes the actual preallocated btree reserve rather than the requested count.

Local validation:

• git diff --check
• make -j32 fs/vfs/swap.o fs/vfs/direct.o fs/vfs/fs.o fs/data/write.o fs/btree/cache.o (userspace/FUSE object path; does not compile the kernel-only swap body)
• make -C /usr/src/linux-headers-7.1-amd64 M=$PWD/tmp/bcachefs-swapfile-dkms-build modules -j32 after staging the DKMS tree under tmp/; this compiled src/fs/bcachefs/vfs/swap.o and linked src/fs/bcachefs/bcachefs.ko successfully. The temporary build tree was removed after validation.
• tests/bcachefs: cover swapfile reclaim pressure ktest#63 is open and green for the companion swapfile reclaim-pressure test (build-and-format).

[koverstreet]

Thanks for the port — it's a conscientious one (authorship preserved, the debug scaffolding from the old draft dropped, and the companion ktest coverage is appreciated). We went through it in detail. The short version: the core swap plumbing is right, but most of the supporting machinery is solving problems the filesystem already solves, and can be deleted outright. That's good news — this PR can shrink to something like 150 lines.

The memory-reserve machinery isn't needed. That means: the btree node pinning walk, bch2_btree_cache_add_reserve()/remove_reserve(), the trans mempool bumps, the GFP_KERNEL→GFP_NOFS conversions in iter.c, the preallocated bkey buffer in the index update worker, and the memalloc_noreclaim_save() calls.

The reasoning: the write path already runs under memory reclaim today. Ordinary dirty page writeback from kswapd goes through the exact same COW machinery — extent updates, journal, btree node splits — with no swap-specific reserves. If bcachefs needed pre-pinned btree nodes or pre-allocated buffers to complete a write under memory pressure, plain writeback would deadlock without any swapfile involved. The forward-progress guarantee is the one the write path already provides: mempools sized so one I/O can always complete, plus the existing btree cache reserve for interior updates. Swap writeback isn't more constrained than page writeback — it's just louder when it fails.

On the specifics:

• vmscan already sets PF_MEMALLOC before calling into swap writeout, so swap_rw's memalloc_noreclaim_save() and the flag propagation into the index update worker re-assert context the caller already established.
• The pinning also has a correctness problem even if it were needed: it pins the node set that exists at swapon time, but btree nodes are copy-on-write — every update replaces nodes, replacements aren't pinned, and the pinned set goes stale as soon as swap traffic starts. (If range pinning were ever wanted here, bc->pinned_nodes_start/end pins by position at eviction time and survives COW — it's what journal replay uses. But per the above, it isn't wanted.)
• The GFP_NOFS conversions are redundant for swap (PF_MEMALLOC_NOFS scoping already makes every allocation in the section NOFS) and a reclaim pessimization for every other user of those paths.
• The diagnostics counters are module-global statics shared across all filesystems; if we want swap I/O latency visibility it should go through the existing time_stats machinery, per-fs.

What stays: swap_activate/swap_deactivate/swap_rw routing into the existing dio paths, and the IS_SWAPFILE() adjustments in bch2_direct_write() — though those want restructuring: six scattered if (!IS_SWAPFILE()) checks plus a goto swap_skip_checks into the middle of the function would be cleaner with the common write core factored out. Also, don't pair a skipped bch2_pagecache_block_get() with a put that re-evaluates IS_SWAPFILE() at a later time — record whether the lock was taken in the dio struct.

The one open design question with real substance is ENOSPC. COW means even overwrites allocate, so a full filesystem can fail swap writes and turn memory pressure into an OOM spiral. The full-file reservation at swapon is one answer, but it needs the reflink/snapshot interaction closed: nothing currently prevents the swapfile being reflinked, or its subvol snapshotted, while active — which invalidates the reservation math exactly when it matters. The other answer is requiring swapfiles to be nocow, like other filesystems require them to be fully allocated: writes go in place, nothing allocates in the swap path, and the problem disappears (at the cost of checksummed/replicated swap). We need to settle that before the next revision — hold off on reworking until we do.

(Review by Proof of Concept, discussed with Kent.)

[rkjnsn]

The other answer is requiring swapfiles to be nocow

nocow doesn't inherently address the snapshot and reflink issue, though, right? Per the PoO, “snapshots and reflink still trigger COW semantics even for nocow files.” If so, that will need to addressed orthogonality to whether swap files are nocow. (Perhaps by reserving enough space at the time of snapshot / reflink to guarantee the swapfile can been fully cow'd, or disallowing those operations?)

Nocow disables encryption, which seems undesirable for potentially highly-sensitive swap contents.

[koverstreet]

You guys are waaaaaaaaaaay overthinking this. The IO paths are already memory reclaim safe, there's no need for btree cache pinning or anything like that, it shouldn't be touching nocow. The only thing that needs to be done for swapfile support is whatever the VFS interfaces need so it can be flipped on.

[dblsaiko]

Just rebased this on master to test it out, immediately got a panic when running swapon. I haven't been running my own rebase of the original patchset for a while but I haven't had that happen with that one on the same FS.

"trans->restart_count 11, should be 8, last restarted by bch2_swap_rw+0x306/0x4b0 [bcachefs]". drm-panic link