Choosing a Linux Filesystem

Introduction¶

The filesystem choice mostly matters at the extremes — huge volumes, heavy metadata workloads, or a need for snapshots/checksums. For a typical server, ext4 or XFS and move on.

The options¶

ext4¶

• The long-time default. Journaling, mature, predictable, well-understood recovery tools (e2fsck, debugfs).
• Grows online (resize2fs), shrinks offline (unusual — most don't).
• Fine up to ~50TB; metadata performance is okay but not the best at extreme scale.
• Pick it when: you want boring and reliable, small-to-medium volumes, broad compatibility.

XFS¶

• Default on RHEL. Excellent parallel I/O and metadata performance, scales to huge volumes and file counts, allocation groups for concurrency.
• Grows online, cannot shrink at all. Size up generously.
• Great for databases, large media stores, anything with many concurrent writers.
• Pick it when: large volumes, high concurrency, RHEL, or you never need to shrink.

Btrfs¶

• Copy-on-write. Snapshots (instant, cheap), checksums (detects bit rot), transparent compression, subvolumes, built-in RAID 0/1/10 (RAID ⅚ still not recommended for critical data).
• btrfs send/receive for efficient incremental backups.
• Overhead and historically some stability concerns under specific workloads (heavy random writes, near-full volumes); much better now, and the default on Fedora and openSUSE.
• Pick it when: you want snapshots/rollback (openSUSE's snapper), checksum integrity, or flexible subvolume layout, and can accept the CoW performance profile.

ZFS¶

• The gold standard for data integrity: checksums everything, self-healing with redundancy, snapshots, clones, send/receive, compression, dedup (rarely worth it), ARC caching, RAID-Z (no write hole).
• Not in the mainline kernel (CDDL licence) — a DKMS/out-of-tree module (OpenZFS). Works well but couples you to kernel updates.
• Wants RAM (rule of thumb ~1GB per TB for comfortable ARC; ECC RAM strongly recommended).
• Pick it when: storage server / NAS, backups, anything where silent corruption is unacceptable and you'll give it RAM and manage the module.

tmpfs¶

• RAM-backed (falls to swap under pressure). Volatile. For /tmp, build scratch, caches you can rebuild. Fast; gone on reboot.

Journaling and CoW¶

• Journaling (ext4, XFS) — metadata (and optionally data) changes are written to a journal first, so a crash leaves the FS consistent (fast recovery, no full fsck). Doesn't protect against bit rot.
• Copy-on-write (Btrfs, ZFS) — never overwrites live data; writes new blocks, then flips pointers atomically. Enables snapshots and, with checksums, detection + repair of corruption. Costs write amplification and fragmentation for random-write workloads (databases) — tune (nodatacow on Btrfs for DB files, ZFS recordsize).

Decision guide¶

Verification and troubleshooting¶

df -Th                                  # filesystem types
lsblk -f
tune2fs -l /dev/sda1                     # ext4 params
xfs_info /mnt/data                       # XFS geometry
btrfs filesystem usage /mnt              # Btrfs (df lies on Btrfs)
zpool status; zfs list

• df shows space but writes fail "No space left" — inodes exhausted (ext4, fixed count set at mkfs — df -i), or Btrfs metadata full while data has room (btrfs balance), or reserved blocks (ext4 reserves 5% for root by default — tune2fs -m 1).
• Can't shrink XFS — you can't, ever. Back up, recreate smaller, restore.
• Btrfs slow / high CPU on a database — CoW fragmentation. chattr +C on the DB directory before data exists, or mount nodatacow, or don't use Btrfs for that volume.
• ZFS using "all" the RAM — that's the ARC; it releases under pressure. Cap with zfs_arc_max if it fights other apps.
• fsck takes forever (ext4) after a crash — journaling should avoid a full fsck; a full check means the journal was damaged or a forced check (tune2fs -c/-i). XFS repairs are xfs_repair (unmounted).
• Corruption with no redundancy (Btrfs/ZFS) — checksums detect it; repair needs a mirror/RAID copy. Single-disk CoW tells you the file is bad but can't fix it — restore from backup.
• Wrong filesystem for the job discovered late — migrating means copy to a new volume (rsync, xfs_copy, zfs send). Plan volume sizing and FS choice up front.

Related tools and reading¶

• On-site: Linux commands reference.
• Related posts: LVM: grow a filesystem online, mdadm software RAID.