Choosing the Right Linux File System: ext4 vs XFS vs Btrfs – Deep Dive & Best Practices

The article provides an in‑depth analysis of the three most common Linux local file systems—ext4, XFS, and Btrfs—targeted at junior to intermediate operations engineers who need to understand underlying principles, performance trade‑offs, and practical configuration steps.

Chapter 1: File System Fundamentals

1.1 Disk and File System

Disks consist of sectors (typically 512 B or 4 KB). File systems create logical abstractions on top of these sectors, using caching, read‑ahead, and write‑back techniques to mitigate the high latency of mechanical storage compared with memory.

1.2 File System Structure

Key structures include the Superblock (metadata about the whole file system), the inode table (metadata per file), data blocks, and hierarchical directories. Block size influences storage efficiency and I/O performance.

1.3 Journaled File Systems

All three file systems use a write‑ahead log (WAL) to guarantee consistency. ext4 employs an ordered mode, XFS uses a similar approach, while Btrfs implements copy‑on‑write (COW) which provides transactional semantics.

1.4 VFS Layer

The Linux Virtual File System (VFS) abstracts concrete file‑system implementations, exposing a uniform POSIX interface to applications.

Chapter 2: ext4 File System

2.1 History and Positioning

Developed by Theodore Ts’o, ext4 entered the mainline kernel in 2008 and is the default for most desktop and server distributions. It offers backward compatibility with ext3 and supports very large file and volume sizes.

2.2 Core Architecture

+------------------+<- 0
| Super Block      |
+------------------+
| Group Descriptors|
+------------------+
| Block Bitmap     |
+------------------+
| Inode Bitmap     |
+------------------+
| Inode Table      |
+------------------+
| Data Blocks      |
+------------------+
| ...              |
+------------------+<- block size

Each block group contains its own bitmap and inode table, allowing parallel allocation.

2.3 Key Features

Extents replace indirect block mapping, reducing metadata overhead for large files. Allocate‑on‑flush (delayed allocation) improves sequentiality and reduces fragmentation. Both journal and metadata checksums increase data integrity.

2.4 Mount Options & Creation

# Basic creation
mkfs.ext4 /dev/sda1
# Specify block size
mkfs.ext4 -b 4096 /dev/sda1
# Set inode size and count
mkfs.ext4 -I 256 -N 1000000 /dev/sda1
# Disable journal (high risk)
mkfs.ext4 -O ^has_journal /dev/sda1
# Standard mount
mount -t ext4 /dev/sda1 /mnt/data
# Mount with common options
mount -t ext4 -o noatime,nodiratime,errors=remount-ro /dev/sda1 /mnt/data

Common options and their performance impact:

noatime      – do not update access time (significant write boost)
nodiratime  – do not update directory access time (small boost)
relatime     – update atime only when mtime changes (balanced)
barriers     – enable write barriers (data safety, slight slowdown)
nobarrier   – disable barriers (performance gain, risk of corruption)
data=ordered – default journal mode (safe)
data=journal – write data through journal (most safe, slowest)
data=writeback – no data ordering (fastest, riskier)

2.5 Performance Tuning

# View current I/O scheduler
cat /sys/block/sda/queue/scheduler
# Set deadline scheduler (good for databases)
echo deadline > /sys/block/sda/queue/scheduler
# Set noop scheduler (SSD optimal)
echo noop > /sys/block/sda/queue/scheduler
# Adjust read‑ahead size
blockdev --setra 8192 /dev/sda
# Sysctl tweaks for writeback
vm.dirty_ratio = 15
vm.dirty_background_ratio = 5
vm.vfs_cache_pressure = 50
fs.ext4.max_writeback_mb = 1024
sysctl -p

2.6 Fragmentation & Defragmentation

# Show fragmentation status
tune2fs -l /dev/sda1 | grep features
# Online fragmentation check (requires e4defrag)
e4defrag -c /mnt/data
# Defragment a single file
 e4defrag /mnt/data/largefile.dat
# Defragment an entire directory
 e4defrag /mnt/data/
# Defragment the whole file system
 e4defrag /dev/sda1

2.7 Check and Repair

# Show superblock features
tune2fs -l /dev/sda1
# Run a full check (must unmount first)
fsck.ext4 /dev/sda1
# Automatic repair
fsck.ext4 -p /dev/sda1
# Force repair (may lose data)
fsck.ext4 -f /dev/sda1

Chapter 3: XFS File System

3.1 History and Positioning

Originally created by SGI in 1993 for large‑scale storage, XFS was open‑sourced in 2001 and is the default on many enterprise distributions (RHEL, CentOS).

3.2 Core Architecture

+------------------+<- 0
| Super Block      |
+------------------+
| AG 0             |
|  +----------+   |
|  | AGF      |   |
|  +----------+   |
|  | AGFL     |   |
|  +----------+   |
|  | B+Tree   |   |
|  +----------+   |
|  | Data     |   |
|  +----------+   |
+------------------+
| AG 1             |
+------------------+
| ...              |
+------------------+

Allocation groups enable parallel I/O across CPU cores, and all metadata is stored in B+‑trees.

3.3 Journal Mechanism

# External log device (recommended for production)
mkfs.xfs -l logdev=/dev/sdb1,size=10g /dev/sda1
# Internal log (default)
mkfs.xfs /dev/sda1
# Delayed log (best performance, slight risk)
mkfs.xfs -l version=2 /dev/sda1
# Suggested log size: max(64 MB, 64 KB blocks)
mkfs.xfs -l size=131072 /dev/sda1   # 512 MB log

3.4 Creation & Configuration

# Basic creation
mkfs.xfs /dev/sda1
# Specify block size (default 4 KB)
mkfs.xfs -b size=4096 /dev/sda1
# Adjust inode size and max percent
mkfs.xfs -i size=512 -i maxpct=5 /dev/sda1
# SSD‑optimized layout
mkfs.xfs -s size=4096 -i size=512 /dev/sda1
# Show parameters without committing
mkfs.xfs -p /dev/sda1dryrun 2>&1 | head -50
# Create with a specific UUID
mkfs.xfs -uuid 12345678-1234-1234-1234-123456789abc /dev/sda1

3.5 Mount Options

# Standard mount
mount -t xfs /dev/sda1 /mnt/data
# Mount with performance‑oriented options
mount -t xfs -o noatime,nodiratime,logbufs=8,logdev=/dev/sdb1 /dev/sda1 /mnt/data
# View current options
mount | grep xfs
# Remount to change options
mount -o remount,noatime /mnt/data

Common options and impact:

noatime      – improves write speed
nodiratime   – slight performance gain
noquota      – disables quota checks (speed boost)
logbufs=8   – number of log buffers (balanced)
logdev=dev  – external log device (writes faster)
wsync        – sync all metadata (safer, slower)
barrier      – enable write barriers (safer)
nobarrier    – disable barriers (faster, riskier)
largeio      – optimises large I/O (good for big files)

Chapter 4: Btrfs File System

4.1 History and Positioning

Started by Chris Mason in 2007, Btrfs aims to provide modern features such as COW, snapshots, checksums, and integrated volume management. It became the default on openSUSE and SUSE Linux Enterprise in 2014, and has matured enough for production use by 2020.

4.2 Copy‑On‑Write Mechanism

# Initial state
Block A: [Data1]
# Modify Data1 → Data2 (COW)
Block A: [Data1]
Block B: [Data2]
# Metadata now points to Block B; Block A becomes orphaned and will be reclaimed.

4.3 Core Architecture

btrfs_super_block (0)
  └─ chunk tree (allocation management)
  └─ tree root
        └─ root tree (filesystem tree)
              └─ fs trees (one per subvolume)
                    └─ extent tree (data locations)
                    └─ csum tree (checksums)
                    └─ device tree (device info)

Key concepts: Chunk (logical storage unit), Extent (contiguous data region), Subvolume (independent tree that can be mounted), Block Group (data/metadata/system grouping).

4.4 Creation & Configuration

# Basic creation
mkfs.btrfs /dev/sda1
# Multi‑device single‑disk RAID0
mkfs.btrfs -d raid0 /dev/sda1 /dev/sdb1
# RAID10 across four devices
mkfs.btrfs -d raid10 -m raid10 /dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sdd1
# Disable checksums for performance
mkfs.btrfs -n none /dev/sda1
# Show filesystem info
btrfs filesystem show /mnt/data

4.5 Subvolume Management

# Create a subvolume
btrfs subvolume create /mnt/data/vol1
# List subvolumes
btrfs subvolume list /mnt/data
# Mount a specific subvolume
mount -t btrfs -o subvol=vol1 /dev/sda1 /mnt/vol1
# Delete a subvolume (must be unmounted first)
btrfs subvolume delete /mnt/data/vol1

4.6 Snapshot Functionality

# Read‑only snapshot (common for backups)
btrfs subvolume snapshot -r /mnt/data /mnt/data/snapshot-$(date +%Y%m%d)
# Writable snapshot (for testing)
btrfs subvolume snapshot /mnt/data /mnt/data/tmp-snap
# Delete a snapshot
btrfs subvolume delete /mnt/data/snapshot-20240101
# Show snapshot details
btrfs subvolume show /mnt/data/snapshot-20240101

4.7 Compression Support

# Enable compression on mount (zstd is the best trade‑off)
mount -t btrfs -o compress=zstd /dev/sda1 /mnt/data
# Use lzo (fastest) or zlib (highest ratio)
mount -t btrfs -o compress=lzo /dev/sda1 /mnt/data
mount -t btrfs -o compress=zlib /dev/sda1 /mnt/data
# Online recompression of existing data
btrfs filesystem defragment -r -v -clzo /mnt/data
# Show compression statistics
btrfs filesystem df /mnt/data
# Show space usage per subvolume
btrfs filesystem du -s /mnt/data

4.8 RAID Configuration

# RAID10 across four devices
mkfs.btrfs -d raid10 -m raid10 /dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sdd1
# RAID5 (three devices)
mkfs.btrfs -d raid5 -m raid5 /dev/sda1 /dev/sdb1 /dev/sdc1
# Balance to redistribute data after device changes
btrfs balance start /mnt/data
btrfs balance status /mnt/data
# Add a new device
btrfs device add /dev/sde1 /mnt/data
# Remove a device
btrfs device delete /dev/sdb1 /mnt/data
# Replace a failed device
btrfs replace start -f /dev/sdb1 /dev/sde1 /mnt/data

4.9 Performance Tuning

# SSD‑optimised mount with compression and async discard
mount -t btrfs -o compress,zstd,ssd,discard=async /dev/sda1 /mnt/data
# Disable COW for database‑like workloads
mount -t btrfs -o nodatacow /dev/sda1 /mnt/data
# Disable COW on a single file
chattr +C /mnt/data/databasefile
# Pre‑allocate large files to avoid fragmentation
fallocate -l 100G /mnt/data/largefile
# Defragment and recompress
btrfs filesystem defragment -r /mnt/data
btrfs filesystem defragment -r -c /mnt/data
# Balance to keep usage under 85 %
btrfs balance start -dusage=85 /mnt/data

4.10 Scrub (Online Check) and Repair

# Start a background scrub
btrfs scrub start /mnt/data
# Check scrub status
btrfs scrub status /mnt/data
# Cancel or resume a scrub
btrfs scrub cancel /mnt/data
btrfs scrub resume /mnt/data
# Enable periodic scrub via systemd
systemctl enable --now [email protected]
# Offline check (must unmount)
umount /mnt/data
btrfs check /dev/sda1
# Read‑only repair attempt
btrfs check --readonly /dev/sda1
# Force repair (may lose data)
btrfs check --force /dev/sda1
# Restore from a backup superblock if needed
btrfs check --super-root /dev/sda1

Chapter 5: Performance Testing Methodology

5.1 Test Preparation

# Identify test device
lsblk
# Show current I/O scheduler
cat /sys/block/sda/queue/scheduler
# Drop caches
sync
echo 3 > /proc/sys/vm/drop_caches
# Verify idle I/O
iostat -x 1 10
# Ensure enough free space
df -h /mnt/

5.2 fio Benchmarks

# Install fio
apt-get install fio   # Debian/Ubuntu
yum install fio       # RHEL/CentOS
# Sequential read
fio --name=seq-read --filename=/mnt/test/seq_read --ioengine=libaio \
    --rw=read --bs=1m --size=1g --numjobs=4 --runtime=60 \
    --group_reporting --iodepth=32
# Sequential write
fio --name=seq-write --filename=/mnt/test/seq_write --ioengine=libaio \
    --rw=write --bs=1m --size=1g --numjobs=4 --runtime=60 \
    --group_reporting --iodepth=32
# Random read (4 KB)
fio --name=rand-read --filename=/mnt/test/rand_read --ioengine=libaio \
    --rw=randread --bs=4k --size=1g --numjobs=8 --runtime=60 \
    --group_reporting --iodepth=64
# Random write (4 KB)
fio --name=rand-write --filename=/mnt/test/rand_write --ioengine=libaio \
    --rw=randwrite --bs=4k --size=1g --numjobs=8 --runtime=60 \
    --group_reporting --iodepth=64
# Mixed workload (70 % read)
fio --name=mixed --filename=/mnt/test/mixed --ioengine=libaio \
    --rw=randrw --bs=4k --rwmixread=70 --size=1g --numjobs=8 \
    --runtime=60 --group_reporting --iodepth=64
# Database‑style workload (8 KB, 70 % read)
fio --name=db-workload --filename=/mnt/test/dbtest --ioengine=libaio \
    --rw=randrw --bs=8k --rwmixread=70 --size=2g --numjobs=16 \
    --runtime=120 --group_reporting --iodepth=128 --time_based

5.3 Test Script

#!/bin/bash
# fs_benchmark.sh – file‑system benchmark script
TARGET_DIR="/mnt/test"
TEST_SIZE="2G"
DURATION=60

# Clean previous test files
rm -rf $TARGET_DIR/*

echo "=== File‑system benchmark ==="
echo "Target directory: $TARGET_DIR"
echo "Test size: $TEST_SIZE"
echo "Duration: $DURATION seconds"

echo "[1/6] Sequential read..."
fio --name=seq-read --filename=$TARGET_DIR/seq_read \
    --ioengine=libaio --rw=read --bs=1m --size=$TEST_SIZE \
    --numjobs=4 --runtime=$DURATION --group_reporting --iodepth=32 \
    --direct=1 | tee /tmp/fio_seq_read.log

echo "[2/6] Sequential write..."
fio --name=seq-write --filename=$TARGET_DIR/seq_write \
    --ioengine=libaio --rw=write --bs=1m --size=$TEST_SIZE \
    --numjobs=4 --runtime=$DURATION --group_reporting --iodepth=32 \
    --direct=1 | tee /tmp/fio_seq_write.log

echo "[3/6] Random read..."
fio --name=rand-read --filename=$TARGET_DIR/rand_read \
    --ioengine=libaio --rw=randread --bs=4k --size=$TEST_SIZE \
    --numjobs=8 --runtime=$DURATION --group_reporting --iodepth=64 \
    --direct=1 | tee /tmp/fio_rand_read.log

echo "[4/6] Random write..."
fio --name=rand-write --filename=$TARGET_DIR/rand_write \
    --ioengine=libaio --rw=randwrite --bs=4k --size=$TEST_SIZE \
    --numjobs=8 --runtime=$DURATION --group_reporting --iodepth=64 \
    --direct=1 | tee /tmp/fio_rand_write.log

echo "[5/6] Mixed (70% read)..."
fio --name=mixed --filename=$TARGET_DIR/mixed \
    --ioengine=libaio --rw=randrw --bs=4k --rwmixread=70 \
    --size=$TEST_SIZE --numjobs=8 --runtime=$DURATION \
    --group_reporting --iodepth=64 --direct=1 | tee /tmp/fio_mixed.log

echo "[6/6] Database simulation..."
fio --name=db --filename=$TARGET_DIR/dbtest \
    --ioengine=libaio --rw=randrw --bs=8k --rwmixread=70 \
    --size=$TEST_SIZE --numjobs=16 --runtime=$DURATION \
    --group_reporting --iodepth=128 --direct=1 | tee /tmp/fio_db.log

# Cleanup
rm -rf $TARGET_DIR/*

echo "=== Benchmark completed ==="
echo "Results saved in /tmp/fio_*.log"

5.4 Result Interpretation

Key fio metrics include IOPS, bandwidth (BW), average latency (lat avg), 99th‑percentile latency (lat 99%), and CPU utilization. Example output snippet:

seq-read: (groupid=0, jobs=4)
  read: IOPS=2503, BW=2503MiB/s (2625MB/s)

Typical good values for SSDs: IOPS > 100 k, BW > 500 MB/s, latency < 1 ms.

5.5 iozone Tests

# Install iozone
apt-get install iozone3
# Run an automatic suite up to 2 GB file size
iozone -a -g 2G -i 0 -i 1 -i 2 -f /mnt/test/iozone.test
# Manual write, read, random, and mixed tests
iozone -Ra -g 1G -n 512M -i 0 -i 1 -f /mnt/test/iozone.test
# Export results to Excel
iozone -Ra -+b /tmp/iozone.xls -g 1G /mnt/test/iozone.test

Chapter 6: Scenario‑Based Selection Guidance

6.1 ext4 Use Cases

General‑purpose servers, desktop systems, and environments requiring maximum compatibility.

Workloads with predominantly small files where ext4’s balanced performance shines.

Situations where advanced features such as snapshots, compression, or native RAID are unnecessary.

6.2 XFS Use Cases

Large‑capacity storage (TB‑scale and beyond) where XFS’s allocation‑group design minimizes performance degradation.

High‑concurrency workloads, scientific computing, video encoding, and other CPU‑intensive I/O scenarios.

Large‑file workloads (media archives, backup targets) that benefit from XFS’s extent handling.

Enterprise environments that rely on Red Hat/CentOS defaults and need robust journaling.

6.3 Btrfs Use Cases

Systems that require native snapshots (container image stores, CI pipelines, backup solutions).

Deployments where transparent compression saves bandwidth or storage space (NAS, remote offices).

Environments that prefer built‑in software RAID without extra layers.

Container infrastructures (Docker, k3s) that benefit from COW semantics.

6.4 Decision Matrix (excerpt)

Consideration      ext4   XFS   Btrfs
Maturity           Highest High   Medium
Stability          Highest High   Improved
Large‑file perf    Medium  Highest High
Small‑file perf    Medium  Medium Low
Random I/O         Medium  Medium Low
Max capacity       Medium  Highest High
Snapshots          None    None   Native
Compression        None    None   Native
RAID support       LVM     LVM    Native
Quota management   Quota  Native Qgroup
Downgrade risk     Low     Low    Medium

6.5 Real‑World Cases

Case 1 – E‑commerce web farm: 100 servers with 500 GB SSDs storing static assets. Chosen ext4 with noatime, data=writeback, and SSD discard. Reason: proven stability and sufficient performance for small‑file traffic.

Case 2 – Video surveillance storage: 100 TB NAS handling continuous H.264 streams. Selected XFS with large‑block allocation and external log on a dedicated SSD. Reason: excellent sequential write throughput and minimal fragmentation at petabyte scale.

Case 3 – Private Docker registry: 20 TB of layered images requiring frequent snapshots. Adopted Btrfs with compress=zstd, ssd, and subvolume‑based organization. Reason: native snapshotting avoids extra backup tools and compression reduces bandwidth.

Case 4 – PostgreSQL OLTP database: 500 GB mixed workload. Recommended ext4 (or XFS) with noatime, nodiratime, and data=writeback. Btrfs was avoided due to COW‑induced write amplification.

Chapter 7: Troubleshooting & Data Recovery

7.1 ext4 Common Issues

Read‑only file system: Check mount options, dmesg for errors, verify hardware health (SMART), attempt remount, and run fsck.ext4 -f if needed.

Space not reclaimed after delete: Look for processes holding deleted file handles with lsof +D /mnt/data | grep deleted, stop offending processes, and sync.

7.2 XFS Common Issues

Unable to mount ("Structure needs cleaning"): Run xfs_repair /dev/sda1. If that fails, try xfs_repair -L or specify alternate superblocks.

Quota not enforced: Verify mount includes uquota / gquota, remount with quota options, and reset quotas using xfs_quota -x -c 'off -v' followed by on -v.

7.3 Btrfs Common Issues

ENOSPC despite free space: Use btrfs filesystem df and btrfs device usage to locate metadata exhaustion, then run btrfs balance start -dusage=0 or -musage=0 to free space.

Performance degradation: Defragment with btrfs filesystem defragment -r -c, balance data across devices, or adjust allocation profiles for HDDs.

Snapshot deletion does not free space: Delete the snapshot, then run btrfs balance start to reclaim the space.

7.4 Data Recovery

ext4: Tools such as testdisk, extundelete, and debugfs can recover deleted files or entire directories when the filesystem is unmounted.

XFS: Use xfs_irecover for inode recovery, or rely on xfsdump/xfsrestore if backups exist.

Btrfs: btrfs restore can copy recoverable files from a damaged device, and snapshots can be mounted directly for point‑in‑time recovery.

Conclusion

ext4, XFS, and Btrfs each excel in different scenarios. ext4 offers the highest maturity and broad compatibility, making it the safest default for most servers. XFS shines with large volumes, high concurrency, and big‑file workloads. Btrfs provides modern features such as snapshots, compression, and native RAID, suitable for environments that can tolerate its slightly higher complexity.

Operations engineers should understand these trade‑offs, regularly monitor filesystem health, choose mount options that match workload characteristics, and apply the appropriate tuning parameters to keep production systems reliable and performant.

Staying up‑to‑date with kernel releases and filesystem‑specific changelogs ensures that new optimisations and stability improvements are leveraged promptly.

References

Linux kernel documentation: https://www.kernel.org/doc/html/latest/filesystems/

ext4 wiki: https://ext4.wiki.kernel.org/

XFS documentation: https://xfs.org/index.php/XFS_Documentation

Btrfs documentation: https://btrfs.readthedocs.io/

fio documentation: https://fio.readthedocs.io/

Red Hat storage management guide: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/