Which Filesystem, and Why? ext4 vs XFS vs btrfs/ZFS

A filesystem is the on-disk format that turns a raw block device into files and directories — how inodes, data blocks, free space, and metadata are laid out. Linux does not have one filesystem; it supports many, and which one a given volume uses is a choice made when the volume is formatted. The reason you can ignore that choice most of the time is the kernel's VFS (Virtual File System) layer: ls, cp, cat, open() all talk to VFS, and VFS talks to whichever filesystem driver is underneath. So the commands are identical on ext4, XFS, or btrfs — the differences are in durability, performance, and features, not in how you use them day to day.

That is exactly why the choice is easy to make blindly and worth understanding. The big three you will meet on Linux are ext4 and XFS (both journaling filesystems) and btrfs/ZFS (both copy-on-write). Before comparing them, learn to answer 'what am I even on?' — because the right first move when tuning or troubleshooting storage is to identify the filesystem type.

A journaling filesystem keeps a small on-disk log — the journal — and writes its intent there before it changes the real metadata: 'I am about to update these inodes and this directory.' If power is lost mid-write, the filesystem replays (or discards) the journal on the next mount, so it comes back consistent in seconds instead of needing a long full scan. The journal mostly protects metadata (the structure), which is why a crash can still lose the contents of a file you were writing even though the filesystem itself stays sound. ext4 and XFS both work this way.

The practical split between them:

• ext4 is the mature, general-purpose default. It is rock-solid, well understood, and — usefully — it can be grown or shrunk. If you want one boring filesystem that is right for a root disk, a laptop, or a small server, it is ext4.
• XFS is built for large files and high parallelism: big media, databases, many CPUs writing at once. It scales to huge volumes and sustains heavy concurrent I/O better than ext4, which is why it is the default on RHEL and its rebuilds. The catch that surprises people: XFS can grow but cannot shrink — plan sizes accordingly.

Rule of thumb: unsure or small → ext4; big files, databases, RHEL, or many parallel writers → XFS.

btrfs and ZFS take a different approach: copy-on-write (CoW). They never overwrite data in place. When you change a block, the new version is written to a free location, and only once it is safely on disk does the filesystem flip its pointers to the new block. The old block is left until it is no longer referenced. That one design decision buys three things journaling filesystems don't have natively:

• Snapshots that are nearly free. Because old blocks are only reclaimed when unreferenced, a snapshot is just 'keep pointing at the old blocks too.' You can snapshot a whole filesystem in an instant before a risky upgrade and roll back if it goes wrong.
• Checksums on data, not just metadata. Every block is checksummed, so silent corruption ('bit rot') is detected on read — and on a mirror, repaired from the good copy. Journaling filesystems trust the disk to return what it stored; CoW filesystems verify it.
• Built-in volume management. ZFS especially rolls RAID, pooling, and the filesystem into one layer, so you don't stack LVM + mdadm + a filesystem separately.

None of this is free. CoW filesystems use more RAM (ZFS notably so), the never-overwrite model fragments write-heavy workloads like databases, they are more complex to operate, and ZFS ships out-of-tree on Linux for licensing reasons (it is not in the mainline kernel, so it is an add-on package rather than a built-in). btrfs is in the mainline kernel and is the lighter-weight way to get snapshots and checksums.

Put it together as a decision you can make quickly:

• Default / unsure / needs to shrink → ext4. Mature, predictable, resizable both ways. The safe answer for a root disk or a general server, and the one to reach for when you have no special reason to do otherwise.
• Large files, databases, heavy parallel I/O, RHEL → XFS. Scales and sustains concurrency better; it is RHEL's default for good reason. Remember it grows but never shrinks.
• You want snapshots and data integrity and can pay for them → btrfs or ZFS. Cheap snapshots, checksums that catch corruption, integrated volume management — at the cost of RAM, complexity, CoW fragmentation on write-heavy loads, and (for ZFS) an out-of-tree module. btrfs is the in-kernel, lighter option; ZFS is the heavyweight with the deepest storage features.

And the reassuring part: whichever you pick, the everyday commands don't change — VFS hides the difference, so ls, cp, find, and permissions all behave identically. You choose a filesystem for its durability, performance, and features, then use the machine exactly as you always have.