ext4 vs XFS vs Btrfs and Which File System to Choose

Three file systems cover almost every Linux disk, and the debate over them is mostly settled by what you need to do with the data. This comparison focuses on features you can use, not benchmark numbers that change with kernel versions. The setup commands are in formatting a disk, and the information assumes Linux 6.x.

Side by side

Feature            ext4        XFS         Btrfs
Grow online        yes         yes         yes
Shrink             yes (off)   no          yes (online)
Snapshots          no          no          yes
Data checksums     no          no          yes
Compression        no          no          yes (zstd, lzo)
Max file size      16 TiB      8 EiB       16 EiB
Repair tool        e2fsck      xfs_repair  btrfs check (cautious)

The table is a summary of the kernel and vendor documentation. ext4 shrinks only while unmounted, which is still more than XFS can do. XFS was designed for large files and parallel disk IO, and Btrfs trades some simplicity for features you would otherwise need LVM, a backup tool and a scrub script to get.

ext4: the safe default

ext4 is the file system you choose when you do not want to think about it. It has been the default on Debian and Ubuntu for years, it handles every workload acceptably, and its repair tool is the most tested. It has no snapshots or checksums, so pair it with LVM snapshots and regular backups. Its flexibility to shrink makes resizing partitions forgiving, which suits desktops and small servers.

XFS: big files and parallel writes

XFS is the default on RHEL and its derivatives, and it shines with large files, video, databases and many threads writing at once, because its allocation groups spread the lock contention. It cannot shrink, so size it generously. Features like xfs_growfs work online, and reflink copies are supported on recent versions. Repair needs the file system unmounted, as in repairing with fsck.

Btrfs: snapshots and checksums

sudo btrfs subvolume snapshot -r /home /home/.snap-$(date +%F)
sudo btrfs scrub start -B /home
sudo mount -o compress=zstd:3,noatime /dev/sdb1 /mnt/data

Copy-on-write lets a snapshot cost almost nothing at creation, and checksums let a scrub find silent corruption. With a second copy of the data (RAID1 profile) it can also repair what it finds. Transparent zstd compression often saves a third of space on text and logs. The costs are real: fragmentation on databases and virtual-machine images unless you disable copy-on-write on those paths, a quirky free-space report, and RAID5/6 modes the project still marks as unsafe. See Btrfs snapshots in practice.

A plain recommendation

Laptop or workstation: Btrfs if you want rollback after bad upgrades, otherwise ext4. General-purpose server: ext4, or XFS on RHEL-family hosts. Media storage or a database with large files: XFS. Backup target where snapshots matter: Btrfs. When a vendor image already uses a file system, keep it, because support teams know that one.

What you give up with each choice

Every file system is a set of trade-offs, and the table of features hides the costs. ext4 gives up nothing in compatibility and everything in modern features: no checksums, no snapshots, no compression, and a journal that protects the structure of the file system but not your data. XFS gives up shrinkability and, historically, some small-file performance, in exchange for strong behaviour under parallel load and very large volumes. Btrfs gives up simplicity and predictability: copy-on-write changes how space is accounted, fragments some workloads and asks the administrator to learn new maintenance habits such as balance and scrub.

The choice also affects recovery. When a disk shows errors, ext4 and XFS have mature offline repair tools that most administrators have used. Btrfs offers several recovery paths, and some of them are destructive, so the official advice is to read the documentation before running anything and to restore from backup when in doubt. If nobody on the team has handled a damaged Btrfs volume, adopt it on a system where the backup is good and restores are tested.

Fitting the choice to the hardware

Flash storage changes the picture. Solid-state drives handle small random writes well, so the fragmentation arguments matter less, and the cost of copy-on-write is lower than on spinning disks. Enable periodic trim with fstrim.timer rather than the continuous discard option, which can slow deletions. On a hardware RAID controller or a virtual disk, the file system sees one device, and Btrfs checksums can detect corruption but cannot repair it without a second copy.

Memory and CPU matter for the feature-rich options. Compression and checksumming cost CPU, usually a small amount on modern processors, and deduplication, where offered, costs memory. For a small virtual machine with one core and a gigabyte of memory, the plain choice is often the right one, because the features you would pay for are features the machine cannot spare resources to use.

Snapshots are not backups

A snapshot on the same volume protects against deleting a file or a bad upgrade, and it shares the fate of the disk. If the disk fails, the snapshots go with it. A backup lives on separate hardware, ideally at a separate location, and is checked by restoring from it. Btrfs makes the transport easy with btrfs send and receive, which stream the difference between two snapshots to another volume, and that is a good building block for backups. It does not remove the need for the second machine.

The same rule applies to the frequency of snapshots. Hourly snapshots with a retention of a day, plus daily ones for a month, keep space use predictable. Too many snapshots of a busy volume lengthen some operations and consume space slowly, since blocks referenced by an old snapshot cannot be freed. Prune on a schedule and watch the free-space report from btrfs filesystem usage, which is more accurate than df on this file system.

Migrating and mixing

You are not locked in. Moving between file systems means creating the new one and copying the data, with rsync -aHAX to keep hard links, ACLs and extended attributes. Do it from a live USB or a second disk for a root file system. In-place conversion tools exist for ext4 to Btrfs, and they work, though a fresh format and a copy is the safer route. A mixed setup is normal: ext4 for the boot and root volumes, XFS or Btrfs for the data volume where the features pay off.

Where this does not apply

ZFS is a fourth option with similar features to Btrfs, but its licence keeps it out of the mainline kernel, which affects distribution support. Flash-specific file systems (F2FS) suit SD cards and some phones. Network and cluster file systems are a different category. Performance claims depend on hardware, so measure your own workload with a tool like fio. The kernel ext4 documentation and the Btrfs documentation hold the details.