ext4 & XFS

The two mainstream Linux filesystems — internals and trade-offs

Why These Two

On a modern Linux system, the default root filesystem is almost always ext4 (Debian, Ubuntu) or XFS (RHEL, Fedora Server, Oracle Linux, Rocky, Alma). Both are mature, journaled, extent-based, and production-proven on PB-scale deployments. They differ in design philosophy — and in a few operational properties that will bite you if you pick wrong.

ext4: Evolutionary Line

1. ext2

   1993 — no journal, fast but fragile after crash

2. ext3

   2001 — added journaling (JBD), otherwise same on-disk layout

3. ext4

   2008 — extents, 48-bit block nrs, dir_index, delayed allocation, checksums

ext4 preserves forward and backward compatibility with ext2/ext3 for features not in use — you can mount an ext3 volume as ext4 and vice versa. This lineage is part of its appeal: battle-tested code with incremental, well-understood evolution.

ext4 On-Disk Layout

ext4 divides the block device into block groups, typically 128 MiB each. Each group holds everything needed to allocate files near their metadata — a locality strategy inherited from BSD's FFS.

ext4 Features Worth Knowing

ext4 Tuning

# # Create a filesystem tuned for a specific workload
# mkfs.ext4 -T largefile4   /dev/sdb1      # 1 inode per 4 MiB — huge media library
# mkfs.ext4 -T news          /dev/sdc1     # 1 inode per 4 KiB — Maildir/news spool
# mkfs.ext4 -T largefile     /dev/sdd1     # 1 inode per 1 MiB — sweet spot for bulk
#
# # Explicit inode count override
# mkfs.ext4 -N 5000000 /dev/sde1            # force 5M inodes regardless of size
#
# # RAID stripe alignment (stride = chunk/block, stripe-width = stride * data disks)
# mkfs.ext4 -E stride=16,stripe-width=64 /dev/md0
  

Reserved Blocks

By default, ext4 reserves 5% of the filesystem for root. This prevents unprivileged users from filling the disk and starving systemd-journald, syslog, or anything else that must keep writing. On a 10 TiB data volume, this is 500 GiB wasted — adjust with:

# tune2fs -m 1 /dev/sda1     # drop reserve to 1%
# tune2fs -m 0 /dev/sdb1     # no reserve (fine for data-only volumes)
  

ext4 Command Line

# dumpe2fs -h /dev/sda1 | head -30
Filesystem volume name:   root
Last mounted on:          /
Filesystem UUID:          3f9a1b6e-...
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index
                          filetype needs_recovery extent 64bit flex_bg
                          metadata_csum_seed sparse_super large_file
                          huge_file uninit_bg dir_nlink extra_isize
                          encrypt
Inode count:              6553600
Block count:              26214400
Block size:               4096
Reserved block count:     1310720
...
  

XFS: Scalable From Day One

XFS was designed by Silicon Graphics in 1993 for IRIX — specifically to serve TB-sized video-editing workloads on multi-CPU workstations. Ported to Linux in 2001, merged upstream in 2002. Its entire design is oriented around scalability and concurrency: B+trees everywhere, parallel allocation groups, dynamic inode allocation.

RHEL made XFS the default root filesystem in RHEL 7 (2014), reflecting a quarter-century of production use.

XFS Design Principles

Allocation Groups (AGs)

An XFS filesystem is carved into a small number (usually 4–32) of allocation groups. Each AG is effectively a mini-filesystem with its own free-space and inode indexes. Because allocations within different AGs don't contend for the same locks, XFS scales to many concurrent writers far better than ext4.

B+ Trees Everywhere

• Free-space by block number — locate free runs adjacent to existing data.
• Free-space by length — find a run of exactly N free blocks.
• Inode B+tree — track which inode slots are allocated (inodes themselves are assigned dynamically, no pre-allocation).
• Directory B+tree — O(log n) lookups in directories with millions of entries.
• Extent B+tree inside the inode — maps logical offsets to physical extents for large files.

Dynamic Inode Allocation

XFS does not pre-allocate inodes at mkfs time. New inodes are carved out of free space on demand. Practical consequences:

• You can't run out of inodes while having free space — a common ext4 failure mode.
• Deleted inode space isn't automatically reclaimed to the pool of data blocks until the chunk is empty (this is usually invisible in practice).

Metadata-Only Journal

XFS journals metadata only. File data is never journaled. Ordering is enforced by writing data blocks before the metadata that references them, similar to ext4's data=ordered. There is no data=journal equivalent — if you need that level of durability, put the workload on a FS that supports it, or use application-level fsync.

XFS Features

XFS Tuning

# # Default mkfs is already sane. Tune only when needed.
# mkfs.xfs /dev/sda1
#
# # RAID alignment — sunit in 512B sectors, swidth = sunit * data disks
# mkfs.xfs -d sunit=128,swidth=512 /dev/md0
#
# # More allocation groups for a high-concurrency workload
# mkfs.xfs -d agcount=32 /dev/sdb1
#
# # Larger log buffer — reduces log commit frequency under heavy metadata load
# mount -o logbsize=256k /dev/sda1 /data
#
# # Inspect an existing XFS
# xfs_info /data
meta-data=/dev/sda1   isize=512    agcount=4, agsize=6553600 blks
         =              sectsz=4096  attr=2, projid32bit=1
         =              crc=1        finobt=1, sparse=1, rmapbt=0
data     =              bsize=4096   blocks=26214400, imaxpct=25
         =              sunit=0      swidth=0 blks
naming   =version 2     bsize=4096   ascii-ci=0, ftype=1
log      =internal log  bsize=4096   blocks=12800, version=2
         =              sectsz=4096  sunit=1 blks, lazy-count=1
realtime =none          extsz=4096   blocks=0, rtextents=0
  

XFS Utilities Cheat Sheet

• mkfs.xfs — create
• xfs_info — like dumpe2fs -h, but for XFS
• xfs_admin — change label / UUID
• xfs_growfs — online grow (no offline option)
• xfs_fsr — online defragmenter
• xfs_repair — offline checker/repair (XFS has no fsck.xfs that does real work; the mount-time log replay handles most cases)
• xfs_db — low-level debugger, equivalent to debugfs
• xfs_quota — manage user/group/project quotas

Growing and Shrinking

ext4 vs XFS — Side by Side

Choosing Between Them

Honorable Mentions

Takeaways

• ext4 and XFS are the two production defaults on Linux. Both are journaled, extent-based, and battle-tested.
• ext4 evolved from ext2/ext3 with backward compatibility; XFS was built scalable from day one.
• ext4 pre-allocates inodes (risk of ENOSPC with free space); XFS allocates them dynamically.
• XFS journals metadata only. No data=journal equivalent.
• XFS cannot shrink. Plan capacity conservatively or accept migration downtime.
• Use reflinks (cp --reflink) on XFS for fast CoW copies — huge win for backups and container layers.
• Default heuristic: ext4 for small/shrinkable volumes, XFS for large/concurrent/large-file workloads.
• f2fs for flash-only embedded; bcachefs still baking; ReiserFS is history.