Linux XFS filesystem architecture & tuning

Originally engineered by Silicon Graphics (SGI) for high-performance IRIX supercomputing, XFS is the default enterprise filesystem for Red Hat Enterprise Linux (RHEL), Rocky Linux, and CentOS Stream. Designed from day one for 64-bit multi-terabyte storage arrays and massive multicore parallelism, XFS relies on B+ trees for all internal indexing and divides storage into independent Allocation Groups (AGs) to eliminate lock contention under heavy concurrent I/O.

Allocation Group (AG) architecture & parallelism

The defining architectural feature of XFS is the Allocation Group (AG). When formatted, XFS subdivides the storage device into equal-sized AGs. The default geometry is 4 AGs for filesystems up to 4 TB; for larger volumes each AG is capped at 1 TB (the maximum AG size), so a 16 TB filesystem gets ~16 AGs and a 100 TB filesystem gets ~100 AGs.

Because each AG manages its own locking, multiple parallel application threads can allocate blocks, write files, and allocate inodes simultaneously without waiting on a global lock.

Reflink & copy-on-write deduplication

Modern XFS (v5 on-disk format) supports instantaneous file cloning via Reflink:

# Create an instant copy of a 100 GB VM image or container layer without duplicating storage
cp --reflink=always /srv/vm/template.qcow2 /srv/vm/vm-node-01.qcow2

The clone completes in milliseconds. Both files share the exact same physical blocks on disk. When either file modifies a block, XFS allocates a new extent for the modified data (Copy-on-Write) while leaving unchanged blocks shared.

Formatting & enterprise RAID alignment

1. Formatting aligned for RAID arrays

When creating XFS on top of an mdadm RAID array or hardware SAN LUN, inform XFS of the stripe geometry:

# Example: 4-disk RAID 0 array with 64 KiB chunk size
# su (stripe unit) = 64k, sw (stripe width) = 4 data disks
mkfs.xfs -f \
  -d su=64k,sw=4,agcount=16 \
  -m crc=1,finobt=1,rmapbt=1,reflink=1 \
  /dev/md0

2. Dynamic inode allocation sizing

Unlike ext4 which creates a fixed inode table at format time, XFS allocates inodes dynamically in 64-inode chunks as files are created. By default, up to 25% of the filesystem capacity can be dedicated to inodes. For mail servers or small-file workloads, increase this limit:

# Format allowing up to 50% of storage for inodes
mkfs.xfs -i maxpct=50 /dev/sdb1

# Inspect runtime filesystem geometry and inode allocations
xfs_info /srv/data

3. Recommended mount configuration

Mount XFS with optimized write log buffers and access-time disabling:

# /etc/fstab entry for high-throughput database / analytics storage
UUID=8a4f1082-99b3-4621-82d1-e61ef0a41d02  /srv/data  xfs  noatime,nodiratime,logbufs=8,logbsize=256k,allocsize=64M  0  0

• logbufs=8,logbsize=256k: Increases the size of each in-memory journal log buffer from the default 32 KiB to 256 KiB (the logbufs=8 count is already the default), boosting heavy transactional write throughput.
• allocsize=64M: Sets speculative pre-allocation size for buffered writes, drastically reducing fragmentation for append-heavy sequential logging.

Online growth & capacity planning

Online volume expansion with xfs_growfs

To expand an XFS filesystem after increasing the underlying LVM LV or cloud block volume:

# 1. Expand LVM logical volume by 100 GB
lvextend -L +100G /dev/vg_main/lv_db

# 2. Grow the XFS filesystem while fully mounted and serving live production traffic
xfs_growfs /srv/database

Health inspection & online maintenance

XFS includes sophisticated online and offline repair utilities:

# Online metadata scrub (Linux 4.15+)
xfs_scrub -v /srv/database

# Offline repair if filesystem fails to mount (must be unmounted)
umount /srv/database
xfs_repair -v /dev/vg_main/lv_db