Optimized truncate on disaggregated storage has produced a run of availability and performance reports. They are spread across three projects and none of them is tracked against this epic, so there is no single view of what is left to fix or of what is a WiredTiger problem versus a MongoDB usage problem.

Drive each of the following to resolution, and record for each one whether the fix lands in WiredTiger, in MongoDB, or in how MongoDB uses truncate.

HELP and AF:

• HELP-99633 - [Disagg] Oplog truncation taking very long during PIT restore
• HELP-99461 - 16tb load oplog truncation is spiky
• AF-21295

SERVER:

• SERVER-134701 - [Disagg] Oplog truncation should happen in its own batch
• SERVER-134838 - [Disagg] Speed up oplog truncation application in PIT Restore
• SERVER-134612 - Oplog truncation re-walks every unreclaimed deleted page because each pass starts from a null lower bound
• SERVER-134492 - Improve per-marker overhead of oplog truncation logic
• SERVER-125068 - Remove featureFlagSizeBasedOplogTruncationForDisagg

This ticket is done when every one of the above is closed or has a scheduled owner outside this epic.