The filesystem you format a partition with is a decision most people never think about, since distribution installers pick a sensible default and move on. But ext4, Btrfs, and XFS genuinely differ in capabilities, and the difference matters more once you get into snapshots, resizing, or workloads with specific performance characteristics.

ext4: the long-standing default

ext4 has been the default filesystem for most major Linux distributions for well over a decade, and its defining characteristic is an extremely long track record of stability. It is a traditional, non-copy-on-write filesystem: journaling protects against corruption from unclean shutdowns, but it does not have Btrfs-style built-in snapshots or some of the more advanced features covered below.

mkfs.ext4 /dev/sdX1        # format a partition as ext4
resize2fs /dev/sdX1 50G     # resize (grow or shrink) an ext4 filesystem
e2fsck -f /dev/sdX1         # check and repair an ext4 filesystem

ext4 supports both growing and shrinking, though shrinking requires unmounting the filesystem first, unlike growing, which can often be done live.

For most desktop use, and for a huge share of existing server deployments, ext4 remains a very safe, well-understood choice with broad tooling and documentation.

Btrfs: snapshots and flexibility

Btrfs is a copy-on-write filesystem, meaning modified data is written to a new location rather than overwritten in place, with pointers updated only once the write succeeds. This design is what makes Btrfs’s signature feature, cheap, fast snapshots, possible: a snapshot is essentially a reference to the filesystem’s state at that moment, sharing unchanged data with the live filesystem rather than duplicating it.

mkfs.btrfs /dev/sdX1
btrfs subvolume snapshot /mnt/data /mnt/data-snapshot-20260808

Several distributions, including openSUSE and increasingly others, use Btrfs as the default root filesystem specifically to enable automatic pre-update snapshots via tools like Snapper, making “roll back the entire system to before this update” a fast, routine operation rather than a full backup-and-restore.

Btrfs also supports both growing and shrinking a filesystem, native compression, and built-in RAID-like functionality across multiple devices (distinct from, and not a full replacement for, traditional mdadm RAID).

btrfs filesystem resize +50G /mnt/data     # grow
btrfs filesystem resize -20G /mnt/data     # shrink

XFS: built for scale

XFS was originally developed for high-performance computing workloads involving very large files and high-throughput parallel I/O, and it remains particularly strong in that specific niche. It is the default root filesystem on RHEL and several other enterprise-focused distributions.

mkfs.xfs /dev/sdX1
xfs_growfs /mnt/data     # note: operates on the mount point, not the device

XFS’s most consequential limitation compared to the other two: it does not support shrinking at all, only growing. An XFS filesystem that needs to become smaller has to be backed up, recreated at the smaller size, and restored, there is no in-place shrink operation.

xfs_repair /dev/sdX1     # check and repair (filesystem must be unmounted first)

For workloads XFS was built around, database storage, large media files, high-throughput logging, it generally performs very well. For typical everyday desktop use with mostly small files, the practical difference against ext4 is usually not very noticeable.

Side-by-side comparison

Feature	ext4	Btrfs	XFS
Copy-on-write	No	Yes	No
Native snapshots	No	Yes	No
Grow while mounted	Yes	Yes	Yes
Shrink	Yes (unmounted)	Yes	No
Built-in compression	No	Yes	No
Typical default on	Many general-purpose distros	openSUSE, increasingly others	RHEL and enterprise-focused distros
Best suited for	General-purpose stability	Snapshot-based workflows, flexibility	Large files, high-throughput I/O

Choosing one

For a typical desktop installation with no particular specialized need, ext4 remains a very safe default with the longest track record. If snapshot-based rollback protection (undoing a bad update instantly, or recovering an accidentally deleted file from a recent snapshot) matters to you, Btrfs is worth specifically choosing, and several distributions now make that choice for you by default. If the workload specifically involves large files, databases, or heavy parallel I/O, particularly on server hardware, XFS’s design advantages become more relevant, which is why it remains the default for enterprise-focused distributions built around exactly those workloads.

None of these three is strictly “better” in every dimension; each optimizes for a somewhat different set of priorities, and the right choice depends more on what you actually need from the filesystem than on any one of them being objectively superior.

Frequently Asked Questions

Which filesystem should I use for a normal desktop installation?

ext4 remains a very safe, well-tested default for a typical desktop, with an extremely long track record and broad tooling support. Btrfs is an increasingly common alternative on desktops, particularly since it has become the default on several major distributions, mainly because of its built-in snapshot support, which pairs naturally with tools like Timeshift or Snapper to make “roll back to before that update broke something” trivial. For most desktop users, either is a reasonable choice; Btrfs is worth specifically choosing if you want snapshot-based rollback protection without extra configuration.

Can I shrink a Btrfs or XFS filesystem?

Btrfs supports both growing and shrinking, unlike some other filesystems, though shrinking a Btrfs filesystem while it is heavily fragmented can be slow and is generally best done with adequate free space available to work with. XFS explicitly does not support shrinking at all, only growing; an XFS filesystem that genuinely needs to become smaller must be backed up, recreated at the smaller size, and restored, rather than shrunk in place. This is one of the more consequential practical differences between the three when planning storage that might need to change size later.

What are Btrfs snapshots and why do people care about them?

A Btrfs snapshot is a space-efficient, point-in-time copy of a subvolume, using copy-on-write so that unchanged data is shared between the snapshot and the live filesystem rather than duplicated, meaning a snapshot initially takes up very little extra space. This makes “take a snapshot before a risky system update, roll back instantly if something breaks” a practical, fast operation rather than a full backup-and-restore cycle, which is why several distributions (particularly ones using Btrfs as the default root filesystem) integrate automatic pre-update snapshots directly into their package manager workflow via tools like Snapper.

Is XFS better than ext4 for large files or high-performance workloads?

XFS was specifically designed for high-performance scenarios involving large files and high-throughput, parallel I/O, and it generally handles very large files and filesystems more efficiently than ext4, which is part of why XFS is the default root filesystem on RHEL and several other enterprise-focused distributions. For typical desktop workloads with mostly small, everyday files, the practical performance difference between ext4 and XFS is usually not very noticeable. The difference becomes more meaningful specifically for server and storage workloads involving large files, databases, or heavy parallel I/O, which is the scenario XFS was actually built around.

What does copy-on-write mean and why does Btrfs use it?

Copy-on-write (COW) means that when existing data is modified, the filesystem writes the change to a new location on disk rather than overwriting the original data in place, only updating pointers once the new write completes successfully. This is what makes Btrfs snapshots cheap and fast, since a snapshot is just a reference to the filesystem’s state at that point, and it also provides strong protection against certain kinds of corruption, since an interrupted write (from a crash or power loss) leaves the original, still-valid data untouched rather than leaving a half-written, corrupted file in place. ext4 and XFS are not copy-on-write filesystems by design, which is part of why they do not support snapshots natively the way Btrfs does.

Can I convert an existing ext4 filesystem to Btrfs without losing data?

Btrfs includes a conversion tool, btrfs-convert, that can convert an ext4 filesystem to Btrfs in place, and it preserves the original ext4 data as a reversible rollback image for a period after conversion, in case something goes wrong. That said, an in-place conversion carries real risk, and a full, verified backup taken before attempting it is strongly recommended regardless of the tool’s built-in safety net, since a failure partway through a filesystem conversion is exactly the kind of scenario a backup exists to protect against. For most people, backing up and creating a fresh Btrfs filesystem, then restoring data onto it, is the safer and more straightforward path compared to in-place conversion.