Stage 3 · Build
Storage & Filesystems
Filesystem Tuning
Mount options, inode tuning, and benchmarking with fio — optimizing filesystem performance.
Essential Mount Options
Mount options control filesystem behavior. The right options can significantly improve performance, while wrong options can cause data loss or corruption.
| Option | Effect | Recommended For |
|---|---|---|
| noatime | Disable access time updates | All servers |
| nodiratime | Disable directory access time | All servers |
| discard | Enable TRIM for SSDs | SSD-backed storage |
| data=ordered | Journal data before metadata | ext4 default |
| data=writeback | Journal metadata only | Performance critical |
| barrier=0 | Disable write barriers | Battery-backed RAID |
# View current mount options
mount | grep " / "
# /dev/sda1 on / type ext4 (rw,relatime,seclabel,data=ordered)
# Recommended /etc/fstab for production
# /dev/sda1 / ext4 defaults,noatime,nodiratime,data=ordered 0 1
# /dev/sdb1 /data xfs defaults,noatime,nodiratime 0 2
# Apply without reboot
sudo mount -o remount,noatime /noatime is the single most impactful mount option. It eliminates one write per file read, significantly reducing I/O on busy servers.
Inode Tuning
Inodes store metadata (permissions, ownership, timestamps) for each file. The inode count is fixed at filesystem creation. Running out of inodes prevents file creation even if disk space is available.
# Check inode usage
df -i
# Filesystem Inodes IUsed IFree IUse% Mounted on
# /dev/sda1 6553600 234567 6319033 4% /
# Inodes per block group (ext4)
dumpe2fs -h /dev/sda1 | grep "Inodes per group"
# Inodes per group: 8192
# Check total inodes
dumpe2fs -h /dev/sda1 | grep "Inode count"
# Inode count: 6553600
# XFS inode statistics
xfs_info /dev/sda1 | grep isize
# isize=512For workloads with millions of small files (email servers, caches), increase the inode ratio with mkfs.ext4 -i 4096. For large files, decrease it with -i 65536.
Read-Ahead Tuning
# View current read-ahead
cat /sys/block/sda/queue/read_ahead_kb
# 128
# Increase for sequential workloads
echo 2048 > /sys/block/sda/queue/read_ahead_kb
# For databases (random I/O)
echo 32 > /sys/block/sda/queue/read_ahead_kb
# Check block device read-ahead
blockdev --getra /dev/sda
# 256 (sectors = 128 KB)Read-ahead prefetches data into the page cache before it is requested. Higher values help sequential reads but waste memory for random access.
Benchmarking with fio
# Random read (database workload)
fio --name=randread --ioengine=libaio --direct=1 --bs=4k --iodepth=32 --rw=randread --size=1G --runtime=60 --filename=/data/testfile
# Sequential write (bulk storage)
fio --name=seqwrite --ioengine=libaio --direct=1 --bs=128k --iodepth=16 --rw=write --size=10G --runtime=60 --filename=/data/testfile
# Mixed workload
fio --name=mixed --ioengine=libaio --direct=1 --bs=4k --iodepth=32 --rw=randrw --rwmixread=70 --size=1G --runtime=60 --filename=/data/testfileUse --direct=1 to bypass the page cache. --ioengine=libaio uses async I/O for realistic results. Always test with realistic block sizes and queue depths.
Filesystem Features
# ext4 features
sudo tune2fs -O dir_index /dev/sda1
sudo tune2fs -O has_journal /dev/sda1
# XFS features (most are enabled by default)
# Check with xfs_info
# Disable unnecessary features for performance
sudo tune2fs -O ^has_journal /dev/sda1 # Disable journal (DANGEROUS)Most modern filesystem features should be left enabled. Disable only features you understand and have tested in your workload.
Production Checklist
- Enable noatime on all mount points
- Use XFS for databases and large files
- Set appropriate read-ahead for workload type
- Monitor inode usage to prevent inodes exhaustion
- Use fio to baseline before and after changes
- Keep at least 10% free space for filesystem operations
- Enable discard for SSD-backed storage
- Use data=ordered for ext4 (default, safest)
Mount option changes can be applied with remount but should be tested in staging. Some options like barrier=0 can cause data loss on power failure.
Disabling write barriers improves performance but risks data corruption on power failure. Only use barrier=0 with battery-backed RAID controllers orUPS-backed systems.
Mark this lesson complete to store local progress and unlock a cleaner resume path the next time you visit.