-
Type: Task
-
Resolution: Unresolved
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: Replication
-
Storage Execution
-
18
We just keep the data size the same when we recover to a stable timestamp instead of correcting it like we do with counts: https://github.com/mongodb/mongo/blob/f757bc52b926943bc748f0dc33173ab16e980f61/src/mongo/db/repl/storage_interface_impl.cpp#L1025-L1028
This means that the size reported in collStats will be wrong, it also can have the side effect of slowly decreasing the effective size of a capped collection, since the system will think it's more full than it actually is. Validate will fix the size.
- is duplicated by
-
SERVER-11113 Shard maxSize should be more accurate wrt space used/free
- Closed
- is related to
-
SERVER-35565 Change capped collection age-out to be based on collection storageSize, not dataSize
- Closed
- related to
-
SERVER-34977 subtract capped deletes from fastcount during replication recovery
- Closed
-
SERVER-31020 Sharding database creation is slow because of shard disk-usage statistics gathering
- Needs Scheduling