Linux filesystems explained: ext4 vs btrfs vs xfs

level:Beginner

Somewhere in an Arch install you will run mkfs.ext4 /dev/... and create a filesystem on your disk. The command is short, but it hides a decision: which filesystem do you actually want? The internet has strong opinions, and most of them are written for people who run storage servers, not people installing their first Linux desktop. So let me say the conclusion up front, because you are allowed to just take it: for a first install, ext4 is the right default, and you do not need to think harder about it unless you specifically want one feature that ext4 does not have. The rest of this post explains what a filesystem is and what the three main choices actually trade off, so the default is a decision you understand rather than one you copied.

What a filesystem is

Your disk, at the hardware level, is just a very long row of numbered blocks that can each store some bytes. It has no idea what a "file" or a "folder" is. A filesystem is the bookkeeping layer that turns that flat row of blocks into the tree of named files and directories you actually work with. It tracks which blocks belong to which file, where the free space is, what each file is named, who owns it, and when it was last touched. When you save a document, the filesystem decides which blocks to use and records that mapping; when you open it, the filesystem follows the mapping back to the right blocks.

If you have used Windows or a Mac, you already have a filesystem and never had to think about it: Windows formats your drive as NTFS and macOS uses APFS, both chosen for you and hidden behind the installer. Linux is the same idea with the choice made visible. The default it reaches for is ext4, but it shows you the menu instead of deciding silently. The shape of the journey is identical on every operating system: a raw partition is empty space, formatting writes a filesystem onto it, and only then can it be mounted into a directory tree you can browse.

The same three-step path on any OS; Linux just lets you pick the format step.

flowchart LR
  A["Raw partition<br/><i>numbered blocks, no structure</i>"] -->|"format with mkfs"| B["Filesystem<br/><i>ext4, btrfs, xfs...</i>"]
  B -->|"mount"| C["Directory tree<br/><i>named files and folders</i>"]
  C -->|"read and write"| D["Your files"]

Because it is the thing standing between your data and a row of dumb blocks, the filesystem is also where reliability lives. The big question every modern filesystem answers is: what happens if the power dies in the middle of a write? The answers to that question are most of what separates the options below. For the formal definition and a feature-by-feature comparison table, the Wikipedia file system article and the Arch Wiki file systems page are the canonical references.

ext4: the reliable default

ext4 is the fourth version of the "extended filesystem" family that has been Linux's mainstream choice for over a decade. It is the default for a reason: it is mature, fast enough for almost everything a desktop does, extraordinarily well tested, and recoverable when things go wrong. If you have ever used a Linux machine without thinking about its filesystem, it was very likely ext4.

Its key reliability feature is journaling. Before ext4 makes a change, it first writes a note describing the change to a dedicated area of the disk called the journal, and only then performs the change itself. If the power dies mid-write, the system reads the journal on the next boot and either completes or discards the half-finished operation, so the filesystem stays in a consistent state instead of becoming corrupted. That is the same idea Wikipedia's journaling filesystem article describes, and ext4 has been doing it reliably for years.

💡 Tip Use ext4 unless you specifically want btrfs snapshots. It is the default with the fewest surprises, and you can always run mkfs.btrfs instead if you later decide you want the snapshot-and-rollback workflow.

What ext4 does not do is anything clever. It cannot take instant snapshots, it has no built-in compression, and it cannot checksum your data to detect silent corruption. It just stores files, quickly and dependably. For most people that is exactly the right amount of filesystem. It handles individual files up to 16 TiB and volumes far larger than any home disk, so you will not outgrow it.

btrfs: copy-on-write, snapshots, and subvolumes

btrfs (pronounced "butter F S" or "better F S", take your pick) is the modern, feature-rich alternative. It is a copy-on-write filesystem, which is a genuinely different design from ext4. Where ext4 overwrites data in place and uses a journal to stay safe, btrfs never overwrites live data: when you change a file, it writes the new version to fresh blocks and only then updates its pointers to refer to the new version. The old blocks are not touched until nothing references them.

That single design choice unlocks the features people choose btrfs for:

Snapshots. Because old data is never overwritten, btrfs can freeze a point-in-time view of your filesystem almost instantly and at almost no cost: the snapshot just keeps the old pointers around. This is the headline feature. Combined with a tool like Snapper, you can take a snapshot before every system update and roll back to a known-good state in seconds if an update breaks your machine. That rollback story is the single best reason a beginner might choose btrfs.
Subvolumes. A btrfs filesystem can be carved into independent subvolumes that you can snapshot separately, all sharing one pool of free space, without committing to fixed partition sizes in advance.
Transparent compression. btrfs can compress files on the fly, saving space and sometimes even improving speed on slower disks.
Checksumming. btrfs checksums both data and metadata, so it can detect silent corruption that ext4 would never notice.

The nuance, and it matters, is stability. The core of btrfs is solid: per the official btrfs status page, single-disk use, subvolumes, snapshots, compression, and scrubbing are all considered stable and production-ready. But the same page lists btrfs's built-in RAID5/RAID6 as unstable and not recommended for production, because of a long-standing "write hole" problem where a power loss during a parity write can leave data unrecoverable. The practical takeaway: btrfs on a single disk is fine, and that is what a desktop install is.

⚠️ Warning Do not reach for btrfs's own RAID5/RAID6 to protect data across multiple disks. The official status page lists them as unstable and not recommended for production, because a power loss during a parity write can hit the "write hole" and leave data unrecoverable.

xfs: built for big files and parallel IO

xfs is a high-performance journaling filesystem originally developed by Silicon Graphics in the 1990s for serious workstations and servers. Like ext4 it journals for crash safety, but it is engineered around throughput at scale. It divides the disk into independent "allocation groups" that can be written to in parallel, which makes it shine on workloads with many large files and lots of simultaneous read/write activity, such as databases, media servers, and analytics pipelines.

For a single-user desktop, xfs does not give you anything ext4 does not already do well, and it lacks btrfs's snapshots. It is the right tool when your workload is genuinely about moving large files fast and in parallel, which is why it is a common default on big-data and server systems (it is, for instance, the default in Red Hat Enterprise Linux). The Arch Wiki XFS page covers its tuning options if you go that route.

Two filesystems you do not really choose

Two more are worth a sentence each so you recognise them:

f2fs, the Flash-Friendly File System, was designed by Samsung specifically for NAND flash devices like SD cards, eMMC, and phone storage. It is excellent on small embedded flash, but it is a niche choice for a normal SSD-based desktop, where ext4 and btrfs are perfectly happy.
FAT32 (vfat) is not a choice at all for your main system, but you cannot avoid it: the UEFI firmware standard requires the EFI system partition to be FAT. The UEFI specification mandates FAT support, and FAT32 is the recommended variant, so you will format your small boot partition with mkfs.fat -F32 regardless of what you pick for the rest of the disk. The disk partitioning explainer covers why that partition exists in the first place.

ℹ️ Note FAT32 on the EFI system partition is required, not a choice. Whatever you pick for the rest of the disk, the firmware standard forces the ESP to be FAT, so that one small partition is always formatted with mkfs.fat -F32.

Which should I pick?

Pick ext4. For a first Arch install on a single disk, ext4 is the default with the fewest surprises: it is fast, it is the most documented filesystem in Linux, and when something goes wrong the recovery tools and the answers you will find online assume ext4. You will not regret it and you will not outgrow it.

Choose otherwise only for a concrete reason:

Choose btrfs if you specifically want the snapshot-and-rollback workflow, where you snapshot before every system update and can instantly undo a bad one. On a rolling-release distribution like Arch, where you update often, that is a real and reasonable thing to want. Just keep it to a single disk and skip btrfs's own RAID5/6.
Choose xfs if you are building a server or workstation whose job is large files and heavy parallel IO, such as a database or media store. For a laptop, it brings nothing ext4 does not already give you.

If you cannot articulate why you want btrfs or xfs, that is itself the answer: take ext4.

The whole decision, including the parts you do not get to choose, fits on one chart. Follow the branch that matches your situation; if none of the special cases describe you, you land on ext4.

The full filesystem decision, with the forced EFI case included.

flowchart TD
  A["Picking a filesystem"] --> B{"Formatting the EFI<br/>system partition?"}
  B -->|"yes"| C["FAT32<br/><i>forced by UEFI</i>"]
  B -->|"no"| D{"What do you want?"}
  D -->|"want snapshots<br/>and rollback"| E["btrfs<br/><i>single disk</i>"]
  D -->|"huge files,<br/>parallel IO, server"| F["xfs"]
  D -->|"flash card or<br/>embedded device"| G["f2fs"]
  D -->|"first install,<br/>keep it simple"| H["ext4<br/><i>the default</i>"]

How this fits the Arch install

This is the decision behind the mkfs.ext4 command in installing Arch part 1, where you partition the disk and create filesystems on it. If you took the default there, you formatted your root partition as ext4 and your EFI partition as FAT32, which is exactly the recommendation above. If you decide you want btrfs instead, the only change is running mkfs.btrfs on the root partition rather than mkfs.ext4; everything else in the install proceeds the same way. The full walkthrough lives in the Arch install companion hub.

A short close

A filesystem is just the bookkeeping that turns a row of disk blocks into named files, and the main thing that separates the choices is how they stay safe across a crash. ext4 journals and is dependable; btrfs uses copy-on-write to give you near-free snapshots at the cost of a slightly less battle-hardened feature set around its RAID modes; xfs is built for large files and parallel throughput on servers. For your first install, ext4 is the answer, and FAT32 on the EFI partition is not optional. Pick btrfs only when you actively want its snapshots, and xfs only when your workload is genuinely server-scale. Everything else is detail you can learn later, once the system is up and running.