[DOCS-12131] replSetResizeOplog does not reclaim OS disk space Created: 07/Oct/18 Updated: 30/Oct/23 Resolved: 12/Oct/18 |
|
| Status: | Closed |
| Project: | Documentation |
| Component/s: | manual |
| Affects Version/s: | None |
| Fix Version/s: | Server_Docs_20231030 |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Pavel Duchovny | Assignee: | Unassigned |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Participants: | |||||
| Days since reply: | 5 years, 17 weeks, 5 days ago | ||||
| Description |
|
When running replSetResizeOplog to reduce the oplog size the space reduced is not returned to the Operating System. One of the main incentives of reducing an oplog is when you need to reclaim space and do not have any other options. It would be nice to add an option to this command to reclaim this space without the need for running a compact or resync? |
| Comments |
| Comment by Ravind Kumar (Inactive) [ 12/Oct/18 ] |
|
This ticket duplicates ongoing work. |
| Comment by Eric Milkie [ 12/Oct/18 ] |
|
We should update the documentation for this command to indicate that it may be necessary to run compact afterwards on each node where the freed disk space is desired. |
| Comment by Eric Milkie [ 12/Oct/18 ] |
|
This ticket sounds like expected behavior. The same behavior already exists today if you were to delete a lot of data from a regular table; why should capped collections be any different? If you want to reclaim the disk space, you must schedule and run compact manually by hand, since it can be a very expensive and long-running operation. |
| Comment by Eric Milkie [ 12/Oct/18 ] |
|
Can you give an example where the disk space wasn't reclaimed? |