What Are the Best Linux Filesystems in 2020?

Best Linux Filesystems 2020 Featured V2

When formatting a hard disk to install your Linux system, you have to decide on the best Linux filesystem to use. In 2020, the most popular option is EXT4. Is it the best one, though, and if you have alternatives, should you choose them? Let’s see the (possible) options.

EXT4

The “Fourth Extended Filesystem” is fully backward-compatible with EXT2 and EXT3 and is considered the standard for most Linux distributions, remaining as popular as its predecessors.

Best Linux Filesystems 2020 Ext4

It is one of the safest and most stable available options today since it supports journaling, preventing (as much as possible) the loss of data after a system crash or loss of power.

Two of its most important features are “extents” and “delayed allocation,” which smartly manage how the data is written on the storage medium to improve performance and reduce fragmentation.

BtrFS

The “b-tree file system” was initially designed by Oracle and has kept increasing in popularity, to the point many consider it the true successor to the EXT dynasty.

Best Linux Filesystems 2020 Btrfs

Btrfs comes with advanced features, such as automatic defragmentation and transparent compression. It follows a copy-on-write approach, saving new iterations of data and metadata instead of affecting the existing ones (“shadowing”). This also allows for snapshots of different states of the filesystem as well as easy replication, migration, and incremental backups. Online and offline filesystem checks further reduce the possibility of data loss.

BtrFS natively supports RAID, but it doesn’t follow the approach of typical software RAID striping or hardware block mirroring. Instead, it ensures that each block on one device has a copy on another and keeps CRCs for all data. Thus, in case of a failure, it can pull information from backups and checksums to reconstruct corrupted or missing data.

It’s worth noting that BtrFS is also “SSD-friendly” since it automatically disables its features that are useful for mechanical HDDs but could wear out SSDs.

XFS

XFS was created by Silicon Graphics almost three decades ago for their graphics workstations specializing in rendering 3D graphics.

Best Linux Filesystems 2020 Xfs

That’s why XFS remains one of the best options for systems that are constantly reading and writing data. Thanks to the use of “allocation groups” – parts of the filesystem that contain their own inodes and free space – it’s possible for multiple threads to read and write data at the same time in parallel. Support for delayed allocation, dynamically allocated inodes, and advanced read-ahead algorithms help it achieve excellent performance, especially on large-scale storage pools up to hundreds of TB in size.

Its support for journaling is restricted, though, compared to more modern alternatives, and it is arguably more prone to data loss. It also doesn’t scale down well for more typical day-to-day and mostly single-threaded scenarios, like when deleting a bunch of photos from your “Pictures” folder. In other words, it’s great if you’re setting up your own datacenter but maybe not for typical personal use.

F2FS

One of the (relatively) newer filesystems, “Flash-Friendly File System” is one of the best options for use with flash-based storage.

Best Linux Filesystems 2020 F2fs

Initially created for that purpose by Samsung, F2FS splits the storage medium into smaller parts that contain zones that also include smaller parts, and so on, and tries to use many of them instead of reusing the same ones. Combined with its support for TRIM/FITRIM, this makes it friendlier to flash-based media that comes with a finite number of writes.

There’s no point in deep-diving into F2FS’s features since it doesn’t excel in anything compared to all alternatives as far as speed or data security goes, nor in using it with typical media, where every other filesystem would come with a better feature-set. The story changes if talking about flash-based storage, though, for which it was explicitly created.

OpenZFS/ZFS

OpenZFS is a fork of the Zettabyte File System (ZFS) that initially appeared on Sun’s Solaris. Up to 2010, ZFS could be used on Linux primarily through FUSE, due to licensing issues. It was after 2010 that its development started opening up, and in 2016 Ubuntu supported, by default, its open-source version. Since then, when people refer to “ZFS,” they’re usually talking about its open variant instead of Solaris ZFS – that also keeps evolving but on a parallel path.

Best Linux Filesystems 2020 Openzfs

ZFS differs from all alternatives in that it combines the filesystem with a volume manager. Because of that, it doesn’t just manage files and directories but also the physical media on which they reside. Thanks to this, every storage device can be assigned to a pool that is treated as a single resource. If you’re ever out of space, you can add new storage to this pool to expand it, letting ZFS take care of the details.

By managing the media itself, ZFS also excels in its support for RAID. You can set up RAID arrays of most types (RAID 0, 2, 5, etc.) but also use its approach of “RAIDZ.” Unlike typical RAID arrays, RAIDZ uses variable width stripes between the drives it includes, increasing its tolerance on data loss after a power failure.

ZFS also follows a copy-on-write approach, where instead of modifying existing data, it only saves the changes (“deltas”) between the old and new versions. This allows for transparent, smart storage of multiple copies of data, without taking up a lot of space, that can work as backups or snapshots. The user can return to previous states of the filesystem, reverting changes, or do the opposite: pull all changes into clones of existing data.

Those are some of the features that help it nearly eliminate any possibility of data loss – at least, in theory.

JFS

The Journaling File System by IBM was one of the first filesystems that supported journaling, leading to reduced chances of data loss. It uses extents like many other modern alternatives and allocation groups like XFS, aiming to offer high read/write performance.

Best Linux Filesystems 2020 Jfs

By not prioritizing a single feature, it’s a great all-arounder under different workloads for different needs. Unfortunately, this also means that it doesn’t excel in anything. Plus, it has some problems that many people would consider a negative when choosing a filesystem for their storage. For example, it can delay updating its journal indefinitely, increasing the chances of data loss and almost nullifying the fact that it’s a journaling file system. It’s better at parallel writes that are of most use to servers and large databases but performs worse than EXT4 in more popular desktop usage scenarios.

Those are probably the reasons why it’s not as popular as other filesystems, which can either perform faster or be better shielded against data loss.

Which Should You Use?

There’s a reason EXT4 is the default choice for most Linux distributions. It’s tried, tested, stable, performs great, and is widely supported. If you are looking for stability, EXT4 is the best Linux filesystem for you.

If you aren’t afraid of having to deal with a somewhat less mature ecosystem, though, BtrFS may be the better option for you.

For server use where you want to eliminate almost entirely any possibility of data loss and stability is the name of the game, you may want to look into ZFS. To really take advantage of it, though, prepare for a lot of reading. Thankfully, we can help with its initial setup.

For flash media, F2FS is the best option by default.

Whichever file system you choose, remember to fully erase your HDD beforehand if you want to render its existing content almost unrecoverable.

Related:

3 comments

  1. To think of BTRFS as the “the true successor to the EXT dynasty” shows sign of delusions of grandeur and doesn’t serve BTRFS nor anyone.

    EXT has kept it simple for decades, remained compatible to itself and competitive in performance to others. This is why it is the most popular filesystem. There is no dynasty here that needs to be challenged or replaced. If anything then it needs to be copied and taken as an example on what it is all about. Its consistency is what users trust in and trust is what filesystems need to win when these want to establish themselves. In a sense are the filesystems of an OS the equivalent to the banks in the economy. Just as you have to trust a bank to take care of your money does one need to trust a filesystem to do the same with your data.

    So while I admire BTRFS for its many features did BTRFS not overcome one of the fundamental laws in programming, but it has only proved the law right once more: the more complex software becomes the more complicated it becomes for developers to maintain it and for users to use it. As a consequence of this law does complex software contain more bugs and users tend to make more mistakes with it. Its because of this that BTRFS will never take the crown. It isn’t a question about its maturity. The choice of filesystem then is a matter of need versus trust and not a matter of how afraid one is to use it.

    BTRFS is the best filesystem for those of us who need its features and it deserves as much respect and praise as EXT does.

  2. I did some filesystem benchmark comparisons a few years ago, and also a couple months ago (unpublished), and I was surprised at how poorly JFS performed against others.

    I realized, after those first benchmarks, that JFS reflects the design philosophy that has guided IBM practically since the beginning. Doing it quickly is not their primary concern. Doing it *correctly* is. JFS has only the generic set of tunables (see jfs_mkfs(8) and jfs_tune(8)) plus a few utility options to mount (see mount(8)). This makes it nearly impossible to botch up the filesystem under normal usage.

    Contrast that to XFS’s myriad mkfs, admin, and mount options. It was designed to be aggressively fast, using heavy caching and threading. But this reliance on memory core for performance presented a problem to the Irix developers at Mips: What happens if the power fails? One story I’ve heard, is that there were a couple large capacitors that served as backups to the power supply. They held enough charge to keep the motherboard and hard drives going, long enough to flush the buffers to disk in the event of a power outage signal.

    If the story’s true, then it’s a clear situation of a complex (but fully specc’d) software design turning into a more complex (but sufficient, hopefully) hardware design.

    I’m not saying either of these is better than the other. I’m simply pointing out that they have different design priorities, targeting different use cases.

    —–

    FWIW, there is one big thing to help a filesystem to work faster: spread out the disk I/O around different controllers.(*) RAID is one commonly used speed-up, and the built-in RAID-0 for Btrfs performs admirably. But filesystems with discrete journals offer another possibility: make the journal external. Ext3/4, JFS, XFS, and ReiserFS all offer this option. On my desktop, Ext4 and XFS compete for performance, when they have external journals.

    (*)That is to say, if /dev/sd[ab] and /dev/sd[cd] are on different IDE or SATA buses, an Ext4 filesystem on /dev/sdb2 could have a journal on /dev/sdd3. Both buses can do their I/O independently of each other.

Leave a Comment

Yeah! You've decided to leave a comment. That's fantastic! Check out our comment policy here. Let's have a personal and meaningful conversation.