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:

  1. Root Reservation: Portion usable only by root user processes and system functions.
  2. Unallocated: Space not allocated to any files or metadata.
  3. Inodes: Data structures mapping file-blocks.
  4. Replay Journal: Transaction log to prevent corruption on crashes.
  5. 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.

Leave a Reply

Your email address will not be published. Required fields are marked *