Function suppress_write_back 

pub fn suppress_write_back() -> SuppressWriteBack

Declare that reads on this thread are validation, not a reader’s.

receive-pack reads every commit and tree it was sent — once — to prove the push closes, and then never reads them again. Those reads look identical to a client’s from inside the store, so the store cannot tell them apart and the caller must say.

MEASURED on torvalds/linux, oden 2026-09-03: the lazy pool is empty until the instant indexing completes and then grows to 6 778 047 872 B (13 segments) before the push returns — 31 % of the whole store and the largest non-pack thing in it, written for a reader that does not exist. Full table in gunnar/.nornir/storage-levers-2026-09-03.md.

Scope

Thread-local, and that is the point. A receive-pack connection does its ingest, its index and its connectivity walk on one thread and serves nobody; the background absorber runs elsewhere and is untouched, and so is every serving connection. Nothing global is switched off, so a store that is simultaneously answering a clone still warms its cache from that clone.

The eager pool is not affected either: the indexer writes that one directly, not through ExplodedCache::write_back.

It is a guard, not a pair of calls

Restored on drop, including on unwind — a panic inside a connectivity walk must not leave a thread that never caches again.