Linux / ext4 vs XFS vs Btrfs: Differences and How to Choose

When choosing between ext4, XFS and Btrfs, compare distribution support, required features, resizing and recovery procedures before considering which is newer. Consider ext4 for familiar administration and offline shrinking, XFS for servers with large storage and concurrent I/O, and Btrfs when you need native snapshots, compression and data checksums. These are starting points: performance and operational suitability still need to be checked in your environment.

This article compares three local-disk file systems for Linux PCs and general-purpose servers. A file system organizes file contents and information such as names, locations and permissions so they can be stored and retrieved. If the relationship between disks, partitions and mounts is unclear, start with how disks, partitions and file systems differ.

ext4, XFS and Btrfs at a glance

Metadata is management information such as a file's location, size and permissions. Journaling uses a record of changes to help restore file-system consistency after an unexpected shutdown; it does not replace backups or guarantee preservation of every file's contents. Copy-on-Write (CoW) writes modified contents to new space and updates the references to them.

“No” refers to a feature provided by the file system itself. ext4 and XFS can use snapshots supplied by the Logical Volume Manager (LVM), a storage system or a virtualization platform. Block-sharing file copies, such as XFS reflinks, also differ from a point-in-time snapshot of an entire file system. The checksum row concerns ordinary file contents; it does not mean that ext4 and XFS lack metadata protection.

ext4: familiar administration and offline shrinking

ext4, short for Fourth Extended Filesystem, follows the ext2 and ext3 family. The Debian 13 installation guide states that ext4 is selected by default in most cases. It is a useful candidate to consider alongside the distribution's installation and recovery tools when no special features are required. Being a default does not establish that it is always faster or safer than the alternatives. See the official Debian 13 installation guide for the distribution's choices.

ext4's standard data=ordered mode journals metadata and manages the ordering of related data writes. It does not write a second copy of all file contents into the journal. A file system mounting successfully after a power failure therefore differs from an application retaining its final writes. The Linux kernel's ext4 administration documentation explains these modes.

Shrinking is a practical operational distinction. resize2fs can grow a suitable ext4 file system while mounted, but shrinking requires it to be unmounted. Shrinking the root file system generally requires a separate boot environment and downtime. The tool does not resize partitions, so the file system and its underlying storage must be managed separately. Check the resize2fs manual against your environment's support conditions.

For example, if you expect to redistribute disk space between operating-system and data areas later, compare shrinking support and downtime before installation. If rollback snapshots are the main requirement, choosing ext4 alone does not provide them: you also need to design an LVM or other backup and snapshot layer.

XFS: servers with large storage and concurrent I/O

XFS manages storage through allocation groups and is worth evaluating for large files and concurrent I/O from multiple jobs. Red Hat Enterprise Linux (RHEL) 10 uses XFS as its default local file system. If your distribution, storage tools and recovery procedures are already organized around XFS, that operational support is also a meaningful selection criterion. The RHEL 10 file-system comparison and administration guide documents its support and use cases.

XFS grows through xfs_growfs while mounted. Additional space must first be available from the underlying device; enlarging a disk or logical volume alone does not necessarily enlarge the file system. An expansion plan must distinguish the disk, partition, logical-volume and file-system layers.

Avoid describing XFS shrinking as either universally impossible or generally available. The RHEL 10.0 release notes describe limited shrinking within the last allocation group as a Technology Preview, provided that the removed range contains no allocated data or metadata. This differs from a general procedure for shrinking to an arbitrary size. If shrinking matters, do not base your choice on this limited feature: verify the distribution's production support or plan to back up and restore into a smaller new file system. See the RHEL 10.0 notes on limited XFS shrinking and the xfs_growfs manual for the conditions.

Include XFS among the candidates for a file server or a server storing large data files, but do not decide from file size alone. Check small-file creation and deletion frequency, concurrency, synchronous writes and latency requirements under conditions resembling the actual service.

Btrfs: combining snapshots, compression and checksums

Btrfs uses CoW and provides subvolumes, snapshots, transparent compression, and data and metadata checksums. A checksum is a verification value calculated from stored contents and used to detect changes when they are read back. Fedora uses Btrfs by default in its desktop editions and spins, but a desktop default does not imply support for every server or disk configuration. See the official Btrfs feature introduction and Fedora's Btrfs guidance.

A subvolume is a directory tree that can be managed independently within a file system. A snapshot initially shares data blocks with its source and consumes additional space as contents change. This can preserve a pre-update state, but selecting Btrfs alone does not configure automatic snapshots, retention or a boot recovery menu. Check the distribution's tools and subvolume layout together.

Snapshots on the same disk do not replace a separate backup. The source and snapshot depend on the same storage and shared blocks, so device failure or damage to a shared block can affect both. Nested subvolumes are not included recursively in a parent's snapshot. Applications actively writing data, such as databases, also need an application backup or a write-quiescing procedure to obtain a consistent state. The Btrfs subvolume and snapshot documentation explains snapshot scope and limitations.

Error detection and recovery are separate capabilities. btrfs scrub checks checksums and other information, but repairing damaged contents requires a verified good redundant copy of the affected block. If a single-disk configuration stores only one copy of the data, a checksum can reveal damage without providing a copy from which to restore it. Files configured with NOCOW are also an exception to data checksumming. The official Btrfs scrub documentation explains the checking and repair conditions.

Compression can reduce space usage and I/O depending on the data, but already-compressed video or archives may gain little. For virtual-machine (VM) images or databases with frequent overwrites, consider CoW, fragmentation and snapshot retention together. Applying NOCOW indiscriminately for performance also affects data checksums and compression. See the Btrfs mount-option documentation for the interactions.

When combining disks, check each Redundant Array of Independent Disks (RAID) profile separately. The official feature introduction describes RAID5/6 as experimental and not production-ready. Do not treat these profiles as equivalent to the others; check the kernel and tool versions alongside the Btrfs feature status.

Which file system fits your environment?

The following criteria connect feature differences to practical requirements. They are not a ranking or a universal configuration recommendation.

If your main goal is to roll back the operating system after a failed update, check which subvolumes the recovery tool actually restores, as well as Btrfs's features. The design differs depending on whether user data should remain current or return to the same point as the operating system. On a server whose data area only grows, distribution support and expansion and backup procedures may matter more than shrinking.

Conditions to match in a performance comparison

A file-system name alone does not predict speed. Even on the same SSD, creating many small files, reading a large file sequentially and performing synchronous database writes can produce different results. Short copy tests can also be strongly affected by memory caching.

• Storage: Use the same SSD or HDD, connection, occupancy and free-space conditions.
• Workload: Match file sizes and counts, read/write ratio, sequential or random access, and concurrency.
• Features and settings: Record compression, CoW, snapshots, encryption and mount options. Do not compare enabled and disabled features as though conditions were identical.
• Durability: Match application synchronous writes and device cache policies. Weakening data-preservation guarantees is not simply a performance improvement.
• Versions and measurements: Record kernel and administration-tool versions, and examine latency and run-to-run variation as well as throughput.

For a log-storage server, for example, test overlapping log appends, rotation, compression and backups rather than copying one large file. Weigh the reduction in storage usage from compression against its CPU cost. If the measured advantage is small, also consider the migration cost and risk of changing the existing file system.

Check the current format and plan any changes

Inspect the current system without changing it

On a typical Linux system, the following commands query devices, mounts and capacity. lsblk and findmnt come from util-linux; on GNU/Linux, df normally comes from coreutils. These commands do not create or change the file-system format.

lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS
findmnt -T / -o TARGET,SOURCE,FSTYPE,OPTIONS
df -hT /

Use lsblk to inspect device relationships and FSTYPE, and findmnt to see the type and active mount options for the file system containing the root path. df -hT / shows that file system's type and capacity. Substitute your actual data directory for / to inspect that path.

For example, if findmnt reports xfs in FSTYPE, that path is on XFS. A disk's own FSTYPE may be blank while a partition or logical volume shows the format. A container may report overlay; do not assume this is the host disk's format. If an older lsblk does not support MOUNTPOINTS, use MOUNTPOINT. Consult the lsblk manual and findmnt manual for option details.

If Btrfs space usage differs from expectations, btrfs filesystem usage can show data, metadata and device allocation together. Deleting files may not immediately release their space if snapshots still reference the data. Instead of relying only on directory-size totals, apply the explanations in the Btrfs space-usage and resizing documentation.

A migration sequence for a different file system

Running another format's mkfs on an existing file system is not a data-preserving conversion. A general migration plan is easier to reason about when built around a new destination and verified restoration.

1. Identify the source device, format and mount point, check application support, then back up to independent storage and verify that restoration works.
2. Prepare the destination file system on a new disk or separately available area. Confirm again that it is the intended empty target before formatting.
3. Obtain consistent data through service downtime or the application's own backup mechanism. Copy or restore the required ownership, permissions, Access Control Lists (ACLs), extended attributes and hard links. Do not assume a tool that copies file contents preserves all this information.
4. Verify files and applications at the new path, then update /etc/fstab and service settings using the new file-system identifier, or UUID. Moving an operating-system root requires a separate procedure covering the bootloader and early boot environment.
5. After rebooting, check mounts, services and permissions. Keep the source and backup until the switch is verified so that, if problems occur, you can stop writes to the new destination and return to the verified original and settings. Include data created after the switch in the rollback plan.

Layer ordering also matters when resizing without changing formats. Typically, expand the underlying storage before growing the file system; when shrinking is supported, shrink the file system before reducing its underlying storage. Btrfs resizing does not automatically update the partition table either. This principle is not a complete procedure: encryption, LVM and RAID each require their own supported steps.

Use tools appropriate to the file system when investigating errors. ext4's e2fsck, XFS's xfs_repair and Btrfs checking and recovery tools are not interchangeable. In particular, do not use btrfs check --repair as a routine first fix. The official documentation advises against it without guidance from a developer or experienced user. Review fsck and precautions for file-system-specific checks and the Btrfs checker warning, and prepare backups and a recovery plan before making changes.