Like every other subsystem, Linux can’t decide on just one filesystem.

Originally, it was ext (1992), then ext2 (1993), followed by ext3 (2001), and ext4 (2006).  There’s also XFS, which started in 1994 with SGI for its Irix operating system and was ported to Linux in 2001.  reiserfs was introduced in 2001 but removed for obvious reasons.  btrfs came along in 2009.  Sun Microsystems started work on ZFS back in 2004 and it was later ported to Linux.

Over the years, the filesystem used by different distributions has changed.  What’s the current landscape look like?  Here are the defaults:

Essentially, if your distro uses dnf (the yum successor), you’re on XFS (unless you’re running the more experimental Fedora), otherwise it’s ext4.  On most of these distros, you can choose other options at install time, and certainly you can if you’re creating new partitions.

So…why would you care?

For most users, you probably don’t.  If you’re running a small-to-medium-sized mail server, web server, database server, or game server, it’s unlikely that you’re going to drive the filesystem layer hard enough to see a difference.  Note that I said the filesystem layer.  You can certainly overdrive your I/O (i.e., the physical disk limits) but you’ll likely overdrive it just as much whether you’re using ext4 or XFS.

There are some technical differences, especially between btrfs and the others.  ext4 and XFS are journaling filesystems.  This means that changes (for example, to change a file or delete a file) are first written to a special part of the disk which is an appending log of all the changes.  Then these changes are flushed to the actual areas of disk where these files reside.  This makes the filesystem both faster (appending to a disk area is faster than seeking and writing to many random locations) and more recoverable.  If the OS powers off in the middle of a write, it’s more likely that the journaling has taken place and the filesystem can be recovered on mount.

Why Choose btrfs?  Features

btrfs is a “copy on write” filesystem, which is a different, more complex architecture.  CoW filesystems never overwrite data in place; instead, they write new copies of modified data and update pointers only after the write completes, which allows features like snapshots and rollback but can add overhead for frequent small writes.

btrfs may indeed be the future of Linux.  Not only does it offer snapshots and rollback, but subvolumes and built-in compression as well.  However, these features are still maturing to some extent, which is why btrfs is not the default in mission-critical distributions like RHEL.

Why Choose XFS?  Because You’re Enterprise

Besides being very mature, XFS supports bigger volumes and files.  ext4’s maximums are 1 exabyte and 16TB, respectively.  So with ext4, the biggest volume you can make is 1 exabyte and biggest file you can put on it is 16TB.  XFS scales up to an 8 exabyte volume and an 8 exabyte file.

Now, keep in mind that 1 exabyte = 1,000,000 terabytes.  That’s a lot of space.  However, ext4’s 16TB maximum file size is a real-world limit you could hit in large enterprise environments.  In an enterprise context (think Fortune 500 company, CERN-scale scientific computing, etc.), 16TB is big but not unusual any more.  There are plenty of 16TB databases in the world, for example.

Why Choose ext4?  Because You’re Default (or Have a Lot of Small Files)

Unless you’re approaching those limits, you’re safe with ext4.

ext4 has one other advantage, though you’d need to be at extremes to see it.  If you have a directory filled with many (millions) of small files, ext4 may perform better.  ext4 uses hash tree indexing, which allow fast lookups even when there are millions of entries in a single directory. XFS uses B+ tree directory structures, which have more overhead.  XFS’s implementation shines in scenarios where you’re doing a lot of parallel I/O with large files, but ext4 may beat it out when you’ve got the opposite situation.

However, if you spread these millions of files across multiple directories, ext4’s advantage vanishes.  Also, if you’re working on these files with many parallel processes, XFS’s concurrency advantages may offset its metadata overhead.

Stepping back from these theoretical extremes, ext4 remains a fine choice.  It’s very proven, having been steadily developed for over 30 years.  Tens of millions of Debian, Ubuntu, Gentoo, and Slackware systems run it using every possible scenario all day long, so its got a great track record of proven stability.

tl;dr please?

If you need really big files, XFS is your choice.  Otherwise, ext4.  If your distro comes with their, you’ve got a great filesystem.  If you want to play with cool features, btrfs has more knobs and dials.

The good news is that all three of these are high quality software.  And unlike Windows’s ntfs monoculture, you’ve got choices.

raindog308

Raindog308 is a longtime LowEndTalk community administrator, technical writer, and self-described techno polymath. With deep roots in the *nix world, he has a passion for systems both modern and vintage, ranging from Unix, Perl, Python, and Golang to shell scripting and mainframe-era operating systems like MVS. He’s equally comfortable with relational database systems, having spent years working with Oracle, PostgreSQL, and MySQL.

As an avid user of LowEndBox providers, Raindog runs an empire of LEBs, from tiny boxes for VPNs, to mid-sized instances for application hosting, and heavyweight servers for data storage and complex databases. He brings both technical rigor and real-world experience to every piece he writes.

Beyond the command line, Raindog is a lover of German Shepherds, high-quality knives, target shooting, theology, tabletop RPGs, and hiking in deep, quiet forests.

His goal with every article is to help users, from beginners to seasoned sysadmins, get more value, performance, and enjoyment out of their infrastructure.

You can find him daily in the forums at LowEndTalk under the handle @raindog308.