[SERVER-18025] Option to allocate disk space headroom automatically Created: 14/Apr/15 Updated: 06/Dec/22 Resolved: 19/Feb/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Storage |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | New Feature | Priority: | Minor - P4 |
| Reporter: | Kevin Pulo | Assignee: | Backlog - Storage Execution Team |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||
| Assigned Teams: |
Storage Execution
|
||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||
| Description |
|
Currently, low disk space conditions only cause write operations to fail when the actual attempt to get/use more disk space from the OS fails. It would help (operationally) if writes could additionally fail when the amount of free disk space falls below some configurable threshold (eg. 10GB). This would leave some disk space as headroom that can be used to restore service, as opposed to the alternative of a filesystem that is either completely full or has a uselessly small amount of free space (eg. under 2GB). A simple workaround for this (and the behaviour that I'm effectively asking for) is to allocate on disk a large dummy file of the desired size. This will cause the filesystem to fill up "early", and if this happens the dummy file can be deleted to gain access to the "spare" disk space. |
| Comments |
| Comment by Eric Milkie [ 19/Feb/19 ] |
|
This functionality is best implemented outside the server process. |
| Comment by Daniel Pasette (Inactive) [ 17/Jun/15 ] |
|
With WiredTiger it is not usually possible to recover from an out of disk situation without expanding the underlying volume or moving database files to a new volume. It usually not possible to even start in read only mode because after exiting with an out of disk error, it will try to apply the journal, which requires space and will cause startup to fail. With that in mind, we are going to change the default configuration for WiredTiger to use directoryperdb: I'm not ruling this out as a feature in the future, but for now it is not scheduled. |
| Comment by Ramon Fernandez Marina [ 21/Apr/15 ] |
|
I'm not sure the general case can be solved without pre-allocating that space ourselves, for some other app/user may take over that headroom space in the meantime. A viable approach would be to set the headroom default to 0 to preserve backwards compatibility, and whenever it is non-zero, mongodb would need to allocate or adjust the size of a reserved file. That's the easy case – the minute we want to support directoryperdb this gets complicated fast: is this a per-db headroom or the same headroom is reserved for all databases? The good news is that by enabling directoryperdb moving a directory to a new volume and creating some symbolic links provides an easy way out of this problem. I would expect that, in an enterprise setting, all storage would be configured for eventual scaling so this feature would not be needed. |