-
Type:
Task
-
Resolution: Done
-
Priority:
Major - P3
-
None
-
Affects Version/s: None
-
Component/s: Truncate
-
Storage Engines - Foundations
-
802.982
-
SE Foundations - 2026-10-13
-
2
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
This ticket is done when every one of the above is closed or has a scheduled owner outside this epic.
- is related to
-
SERVER-125068 Remove featureFlagSizeBasedOplogTruncationForDisagg
-
- Open
-
-
SERVER-134838 [Disagg] Speed up oplog truncation application in PIT Restore
-
- Backlog
-
-
SERVER-134612 Oplog truncation re-walks every unreclaimed deleted page because each pass starts from a null lower bound
-
- In Code Review
-
-
SERVER-134492 Improve per-marker overhead of oplog truncation logic
-
- Open
-