Fast truncate is enabled for disaggregated storage, but we have no repeatable measurement of what it buys us over the slow follower path, or of how it affects cache pressure.

Build a benchmark on an oplog-shaped workload that runs the same deletion volume through both paths (fast truncate, and the slow path via debug_mode=(disagg_slow_truncate_follower=true)) and compare:

• deletion throughput and latency
• cache pressure signals: cache_truncate_txn_uncommitted_bytes, cache_eviction_blocked_uncommitted_truncate, dirty bytes, eviction rate
• the layered truncate list statistics (search calls, entries walked, GC runs)

The result should be a baseline we can re-run, not a one-off measurement, so that later changes to the truncate list or the conflict detection path can be evaluated against it.