Learn Linux Filesystem - XFS: Design, Tools & Operations

#Introduction

XFS is Linux's answer to heavy workloads: giant files, media streaming, backup servers, and large databases. Because of its parallelism-oriented design, XFS is the default on RHEL, Rocky, and AlmaLinux. If you work in the Red Hat ecosystem, mastering XFS is a must.

The keys to XFS's design are three: allocation groups, B+trees, and journaling optimized for large scale. Then we'll practice with mkfs.xfs, xfs_info, xfs_growfs, xfs_repair, and the backup pair xfsdump/xfsrestore. One important fact that sets XFS apart from ext4: XFS cannot shrink — it can only grow.

This episode will run most smoothly if you've already mastered the concepts of episode 2, because XFS is a real-world example of how inodes, block allocation, and journaling are implemented differently.

#XFS Design

#Allocation Groups (AG)

XFS divides the filesystem into several allocation groups, each with its own inode table and metadata. Each AG can be allocated independently, so multiple processes can write to the same filesystem in parallel without all contending on one global mutex.

Inspect the AG structure:

sudo xfs_info /dev/loop0

The xfs_info output shows agcount, agsize, blocks, and block size. agcount is usually 4 for small filesystems, and increases for large ones.

#B+trees for Free Space

To find free space, ext4 uses a simpler structure, while XFS uses a B+tree — a balanced structure that finds ranges of free blocks in logarithmic time. B+trees are also used for inodes, so XFS handles tens of millions of inodes without lookup degradation.

The consequence: XFS is very efficient on giant filesystems and parallel workloads, but the metadata cost per file is slightly higher than ext4's.

#Log-Based Journaling

XFS uses a journal called the log, allocated inside the filesystem (or on an external log device with mkfs.xfs -l). The XFS log doesn't store data — only metadata — and is designed for fast recovery after a crash. data=writeback is XFS's default mode, so there's no guarantee data is journaled like ext4's data=ordered.

#Creating and Inspecting an XFS Filesystem

#mkfs.xfs

Format the loopback disk as XFS:

sudo losetup -f /tmp/lab.img
sudo mkfs.xfs -L lab-xfs -f /dev/loop0

The -f option forces reformatting even if a filesystem already exists. To set the log size explicitly: mkfs.xfs -l size=64m. For RAID stripes, you can give -d su=64k,sw=4 according to the array geometry — we'll cover this in episode 8.

#Adding Features with -m

Modern XFS supports per-filesystem features set at mkfs time:

• -m reflink=1: enables reflink/COW (default on modern kernels), the basis of cp --reflink.
• -m rmapbt=1: reverse mapping B+tree, helping recovery and cp --reflink for snapshots.
• -m crc=1: CRC32 for metadata — default since kernel 4.2.

Check the active features:

sudo xfs_info /dev/loop0

Note the ftype=1, reflink=1, and crc=1 lines in the xfs_info output.

#Daily Operations

#Mount and xfs_growfs

Mount the filesystem, then grow it online:

sudo mkdir -p /mnt/lab
sudo mount /dev/loop0 /mnt/lab
sudo xfs_growfs /mnt/lab

xfs_growfs grows XFS to the maximum device size without unmounting. Because XFS doesn't support shrinking, size your partition correctly from the start — a mistake means recreating from backup.

#xfs_repair

XFS checking can't run online like fsck on ext4. xfs_repair must run while the filesystem is unmounted:

sudo umount /mnt/lab
sudo xfs_repair -n /dev/loop0

-n performs a check without changing anything (dry-run). Without -n, xfs_repair will repair structural damage. As a note, XFS is very resistant to corruption thanks to CRC on metadata.

#Backup with xfsdump and xfsrestore

Because XFS has no native snapshot mechanism for a fully consistent filesystem while in use, backups use xfsdump:

sudo xfsdump -l 0 -f /backup/fs.img /mnt/lab

-l 0 means level 0 (full backup). Levels 1-9 store only the changes since the previous level — XFS's built-in incremental backup. To restore:

sudo xfsrestore -f /backup/fs.img /mnt/lab

The xfsdump/xfsrestore pair is XFS's official backup approach, equivalent to snapshots on other filesystems. xfsdump -l 0 is the command most frequently used in daily operations.

#Conclusion

XFS offers a different architecture from ext4: allocation groups for parallelism, B+trees for large scale, and CRC on metadata for integrity. As a consequence, XFS excels at high throughput and large files, but it doesn't support shrinking, and snapshot-based backups need external help.

Key takeaways:

• XFS divides the filesystem into allocation groups that can be written in parallel.
• B+trees make space and inode allocation efficient at giant scale.
• The XFS log stores only metadata; its default data mode is writeback.
• xfs_growfs only grows — XFS cannot shrink.
• xfs_repair must run while the filesystem is unmounted.
• Official backups use xfsdump with incremental levels 0-9.

In the next episode, episode 5, we enter the first COW filesystem: btrfs — subvolumes, snapshots, and Copy-on-Write. You'll see instant snapshots, checksums, and send/receive — the advantages of btrfs — along with its multi-device RAID modes.