A practical guide to filesystems

Table of contents

Filesystems define the layout and structure of data on harddrive partitions. Each filesystem comes with its own set of advantages and drawbacks, making the choice of filesystem quite difficult for operators that aren't familiar with the topic. This article aims to provide a guide on the most common filesystems, why and when to use them, and what to watch out for.

FAT32: Universal compatibility

The most widely compatible filesystem still in use. Its simple design has made it a prime target for support from basically any device: New and old computers, smartphones, cameras - just about anything will recognize and understand a FAT32 formatted storage device.

This unrivaled level of compatibility makes FAT32 an easy choice for shared flash storage, like USB drives or SD cards.

The old age of FAT32 is both blessing and curse: While it enabled the compatibility with any system, it also carries size restrictions that seemed reasonable decades ago. A FAT32 system cannot be larger than 32GB (technically 2TB, but most implementations don't support more than 32GB per FAT32 partition), and no file in it can be larger than 4GB. It also lacks support for file permissions, encryption and defragmentation, making it unsuitable for long-lived needs (like harddrives).

exFAT: Modern compatibility

Aiming to replace FAT32 as the compatibility filesystem, exFAT increased maximum storage and filesize limits to 128PB, while remaining relatively simple in design.

It is a great choice for a filesystem shared between different modern operating systems, for example an external harddrive used by Windows, MaxOS and linux machines.

While it improves on the most important shortcomings of FAT32, it also lacks its backwards compatibiltiy with older devices. exFAT is a solid choice for a solid state storage (usb drive, external harddrive) that is shared between different modern operating systems, but fails to compete with more mature filesystems for home computing or server storage use cases (slower than ext4/NTFS, lacks journaling to prevent data loss during power outages etc).

ext4: Default for Linux

The fourth iteration of the extended filesystem is a mature and fast choice, the default choice for linux installations and the successor to ext2 and ext3. It is heavily relied upon in many usage scenarios, from handheld devices to personal computers and enterprise servers.

Key features include the journaling system that provides some protections against data loss and corruption, its good performance for most computing use cases, and the wide support from the linux community.

While ext4 is a reliable and fast choice for most computing tasks, it may fall short in specific edge cases: The performance starts to visibly degrade beyond 50TB storage size or when exceeding 10k subdirectories. Advanced features like compression and deduplication aren't well supported and the filesystem can only be expanded while mounted, shrinking can only be done on an unmounted partition.

These limitations are rarely an issue outside of large-scale storage setups, making ext4 a solid choice when a reliable filesystem with good performance is needed.

NTFS: Default for Windows

Being the long-standing default for Windows operating systems, NTFS is still widely used on personal computers and workstations. It includes uses journaling to protect the stored data, has reasonable performance and support compression out of the box.

While Windows prefers this filesystem, it has limited support from other operating systems, being read-only in MacOS and needing extra software to work in linux at all. It is slightly slower than ext4 and suffers from data fragmentation, requiring frequent resource-heavy defragmentation passes.

It remains a solid choice for Windows computers, but cannot compete with other filesystem options outside of this use case.

XFS: Optimized for large files

Similar to ext4, the XFS is a reliable and fast filesystem, but optimized for large files. It combines the robust journaling approach for data protection with improved parallel I/O operations (using B+ trees for directory lookups) and a low fragmentation algorithm for writes (so files are written as large consecutive chunks, reducing seek operations). It scales well with higher number of CPU cores and offers best in class performance for files larger than 4GB.

However, the optimization towards large files has drawbacks too: Smaller files, especially those with less than 4KB, incur a much higher overhead than in ext4, the filesystem cannot be shrunk (only expanded), and it is not as widely supported as other options (limited availability of recovery tools etc).

It is best used for systems that need to deal with many large files, like download mirrors or some types of databases.

ZFS: Enterprise-grade filesystem

In contrast to traditional filesystems, ZFS is more like a suite of integrated tools, providing the actual filesystem, but also volume management, snapshots, software RAID, encryption, compression and deduplication out of the box. The ZFS filesystem offers strong data integrity through checksums and a copy-on-write (CoW) approach, avoiding the overhead incurred by journaling systems. It is highly scalable (up to 256 quadrillion zettabytes!), supports extensive performance tuning per use case, advanced caching, encryption, compression and deduplication. It can efficiently handle large sequential reads (e.g. streaming large files) and has built-in self-healing capabilities with scrubbing to protect against data corruption.

All those shiny features come at a cost: ZFS needs much more hardware resources to just to run, recommending 1GB memory per 1TB of storage and the compression and deduplication computations need orders of magnitude more CPU cycles than simpler filesystems without those features. While the many configuration options make it flexible to fit most enterprise use cases, some limitations aren't as easily configured away, for example device pools (software RAID) can't be shrunk (only expanded), compression settings have to be applied per-dataset in advance and creating storage arrays of unevenly sized disks isn't possible.

All those configuration options and caveats require specially skilled employees to manage effectively, but it is very hard to beat in terms of speed and scalability if managed properly. ZFS is best suited for large scale storage systems that can plan their workload ahead of time and have the CPU/memory resources to run it or require the robust data integrity and raid implementations.

Btrfs: The next linux filesystem

Intended to eventually replace ext4, the btrfs filesystem had a rocky start. With some severe issues around performance and reliability in it's early stages, it has gotten a bad reputation that has lingered even after most issues had long been fixed. It is now a viable alternative to ZFS in many cases, but some features like software RAID 5/6 are still not production-ready.

The filesystem brings volume management, compression software raid and copy-on-write snapshots out of the box, with tools available to add advanced features like deduplication and encryption. It primarily differs from ZFS in terms of complexity and performance, typically being the easier filesystem to manage and using less resources by default. It is generally known to be more forgiving for changing workload requirements, allowing users to combine disks of different sizes into a pool, shrinking existing pools without downtime and tuning compression settings for individual files if desired.

Btrfs is licensed under the GPL, allowing it to be built natively into the linux kernel, thus eventually succeeding the current ext4+LVM setup as the default linux filesystem (some distributions like openSuse are already using it by default). ZFS's license is perfectly open source, but fundamentally incompatible with the GPL, so it will remain a third-party package installation.

The flexibility to make large changes at runtime, lower resource usage, lower complexity and better control over compression features make it an excellent filesystem for linux systems that can't predict their future storage needs such as desktops, handhelds and small servers. While it still doesn't quite match the raw performance of ZFS in perfect configuration, it makes up for it in reduced resource usage (especially memory).

Honorable mentions

While the list above contains the most common filesystems in use today, some old ones have carved out a niche that their modern replacement cannot quite satisfy.

One such old system is ext2. In terms of features, it definitely cannot keep up with ext4, but this lack of overhead also makes it incredibly lightweight for the system running it. Setups that need to get every last bit of I/O capacity out of their filesystems still find themselves looking at ext2 as a viable option, especially when data integrity is not a major concern (e.g. when running on hardware RAID).

Another such filesystem is ReiserFS, as its approach to storing metadata allows it to perform well for large amounts of small or tiny files. Where other filesystems like ext4 struggle with large amounts of files smaller than 4KB, ReiserFS was specifically optimized for this use case and can outperform more modern filesystems for this use case even today. It remains efficient even when a single directory contains more than 100k files, whereas ext4 will start to struggle with more than 10k items per directory.

Note that these filesystems aren't a good choice for needs outside of their specific niche, and are not as actively maintained as the options above.


More articles

A primer on LVM

Making the most of your storage devices

Automated security hardening on RockyLinux with OpenSCAP

Securing enterprise linux in less than a minute

Choosing the right RAID setup

Making sense of pros and cons for RAID configurations

Writing practical bash functions

Understanding bash functions from passing arguments to returning values

Measuring software performance with percentiles

Understanding what insights P99, P95 and P50 percentiles provide

Compiling native applications for alpine containers

Making glibc programs run in musl environments