Tuning Reserved Filesystem Space For Optimal Storage Usage
What is Reserved Space and Why Does it Matter?
Reserved filesystem space refers to the percentage of total disk space that is kept unused and allocated for root users only. This space cannot be used by regular users or processes and serves a vital purpose. Having sufficient reserved space enables critical system functions and emergency situations where disk writes would otherwise fail due to a full disk.
The most common system functions that utilize reserved space include:
- Logging – All disk write operations are logged to system logs like dmesg or kern.log.
- Crash Dumps – Core dump files are saved when applications crash unexpectedly.
- Disk Repairs – Filesystem checker utilities create temporary files during scans and repairs.
- Package Installs – New software packages require free space to unpack files.
In addition to supporting essential system functions, reserved space also prevents disk utilization from reaching 100%, which can cause performance issues, prevent application writes, and lead to data corruption or loss. Having available reserved space gives a safety margin for bursts of activity like log spikes during high load.
However, reserving too much space reduces overall disk capacity available to users and applications. Finding the right balance is key to optimizing storage usage. Typical defaults range from 5-10% but often need adjustment based on workload patterns and disk sizes. Later sections cover best practices for calculating ideal reserved space.
How Linux and UNIX Filesystems Allocate Reserved Space
Modern UNIX-like operating systems use advanced journaling filesystems like Ext4, XFS, and Btrfs for storing data. They take slightly different approaches for allocating reserved space:
Ext4
The default Ext4 reserved space percentage is 5% regardless of disk size. This space is segmented into 5 regions:
- Root Reservation: Portion usable only by root user processes and system functions.
- Unallocated: Space not allocated to any files or metadata.
- Inodes: Data structures mapping file-blocks.
- Replay Journal: Transaction log to prevent corruption on crashes.
- Uninit Blocks + Fragmented: Reserved for further writes.
Having multiple bucket segments prevents critical processes from failing if any one segment fills up. Ext4 reservation settings are configurable per file system using the tune2fs
command.
XFS
The XFS filesystem has a dynamic reserved space percentage starting at 10% and scaling down to about 1% as the disk fills up. This gradual tapering prevents wasted space but avoids critically low reserves on large nearly-full disks. XFS reserved space is also divided into inode, metadata, and fragment regions.
XFS reservation settings can be statically configured at filesystem creation time or altered for mounted file systems using the xfs_info
command.
Btrfs
Btrfs does not have an implicit system-wide reservation by default. Instead, it supports configurable per-subvolume quotas that enforce limits on consumed data+metadata space. Free unallocated space outside of quotas serves as available reserved space for repairs, logs, etc.
Subvolume quotas can be enabled with btrfs quota
and fine-tuned to allow sufficient unallocated space for your workload.
In summary, Linux/UNIX filesystems take flexible approaches for allocating reserved space either globally per-filesystem or on a per-volume basis. Later sections provide guidelines for appropriately sizing this space.
Calculating Ideal Reserved Space Percentage
Determining how much space to reserve depends on several factors:
- Disk size – Reserving 10% on a 1TB drive sacrifices 100GB, whereas 5% may suffice.
- Workload writes – Frequently updated logs may need more reserved space.
- Frequency of events like crashes, power outages needing larger crash dumps.
- Growth rate of stored data over time.
As a general guideline, use these filesystem-specific formulas to calculate a starting reserved space percentage:
Ext4
- Disks <= 250GB: 5% to 7%
- Disks > 250GB: 1% to 3%
XFS
- Disks <= 50TB: 7%
- > 50TB: 0.5%, but at least 5GB
So for example, a 2TB Ext4 filesystem would reserve 2TB * 3% = 60GB by default. Make further tweaks based on usage patterns and growth rate projections.
Configuring Per-Filesystem Reserved Space
Filesystem reservation settings are adjustable on a per-filesystem level, allowing each one to be tuned independently.
View Current Reserved Space
Before making changes, check current settings with reporting tools:
# Ext4 tune2fs -l /dev/sdX | grep -i reserve # XFS xfs_info /mountpoint # Btrfs btrfs filesystem usage /mountpoint
Temporarily Override
Tune reservation settings without permanently altering superblock metadata:
# Ext4 tune2fs -m X /dev/sdX # XFS xfs_io -x rsvpct=Y /mountpoint
Useful for testing changes over a period before committing.
Permanent Mount Changes
Define permanent reserved space settings in the /etc/fstab config file, e.g:
UUID=fs-uuid /data ext4 defaults,reserve=5% 0 0 /dev/btrfsvol /logs btrfs defaults,subvol=/@logs,quota=2G 0 0
Will enforce a 5% Ext4 reservation and 2GB Btrfs subvolume quota at every mount.
Monitoring Free Space Over Time
Continuously monitoring free disk space is advised to validate configured reservations meet needs during actual usage over an extended period:
Monitoring Tools
- df – Show overview of space usage for all mounts.
- pydf – Enhanced df written in Python with usage graphs.
- kdf – Dynamic real-time utilization tracker.
Alerting
Trigger alerts when reserved space is fully utilized for early warning:
* * * * * /script/check_disk_full.sh && notify_admins
Take proactive steps like rotating/deleting logs or adding storage before issues occur.
Example Configurations for Common Setups
Determining optimal reserved space settings requires understanding workload patterns and growth rates. Here are example starting points for typical server configurations:
Single Disk Server
1TB Disk Ext4 Root (/) - 256GB - 7% (18GB) Ext4 Web Files (/var) - 512GB - 5% (26GB) XFS DB Logs (/dblogs) - 256GB - 7% (18GB)
Software RAID Array
4 x 2TB RAID 5 Array (6TB Total) XFS Media (/media) - 5TB - 3% (150GB) Ext4 Backup (/backup) - 1TB - 5% (50GB)
Virtual Machine Image
256GB Disk Ext4 Root (/) - 64GB - 5% (3.2GB) Ext4 Application (/app) - 192GB - 2% (3.8GB)
PostgreSQL Server
2 x 512GB SSD ZFS Mirrored Pool (512GB Usable) ZFS data (/pgdata) - 256GB - NO reserve ZFS logs (/pgsql) - 128GB - NO reserve ZFS archive - 128GB - NO reserve ------------------ + 64GB Unallocated (12%)
Allows 12% equivalent space for PostgreSQL background tasks without explicit reserve allocation.
Base initial reserved space estimates on server role, then review growth rates over time and tune higher or lower as necessary.