Alright, let’s talk filesystems. This is one of those moments where your choice actually matters, far more than your distro’s default would have you believe. Picking a filesystem isn’t like picking a wallpaper; it’s foundational. It dictates how your data is stored, how it’s recovered when things go sideways, and what nifty tricks your storage can perform. We’re going to look at the big four for Linux: the old reliable, the speed demon, the young contender, and the beast from beyond. Strap in.

The Old Guard: ext4

If you’ve used Linux for more than five minutes, you’ve met ext4. It’s the default for a reason: it’s the logical endpoint of decades of evolution. It’s the Toyota Corolla of filesystems—incredibly reliable, utterly predictable, and about as exciting as a stapler. And you know what? Sometimes you just need a stapler.

It does journaling, which is like a meticulous accountant keeping a ledger of every operation. If the power cuts out, the journal lets it replay the last few entries and get your filesystem back to a consistent state without a lengthy fsck. It’s rock solid for 99% of use cases.

The code to create one is exactly what you’d expect:

# Formatting a partition (let's say /dev/sdb1) as ext4
sudo mkfs.ext4 /dev/sdb1

# To enable some slightly more modern features like bigger-than-2TB-files, use the -T largefile flag
sudo mkfs.ext4 -T largefile /dev/sdb1

The rough edges? It’s a bit… basic. While it supports things like file encryption and huge directories now, it feels bolted on. Its scalability, while good, starts to wheeze compared to XFS when you’re dealing with millions of tiny files. It’s your safe bet. Boring, but effective.

The Speed Demon: XFS

Developed by SGI for their massive IRIX systems, XFS is the filesystem you choose when you have a need for speed, especially with large files. Its design is all about concurrency and maximizing throughput. Think of it as the filesystem for the professional video editor or the database server that can’t afford to wait.

Its journaling is excellent, and its performance under heavy parallel I/O loads is often unmatched by ext4. However, its historical Achilles’ heel was xfs_repair. If an XFS filesystem gets corrupted, the repair process can be… let’s be direct, it can be a nightmare. It’s gotten much better in recent years, but the old reputation still lingers. The other quirk is that you cannot shrink an XFS filesystem. You can grow it live all day long, but shrinking is a non-starter. Plan your storage accordingly.

# Creating an XFS filesystem is straightforward
sudo mkfs.xfs /dev/sdb1

# To mount it with performance options, you might use noatime to reduce write overhead
# Edit your /etc/fstab entry to look something like:
# /dev/sdb1  /mnt/data  xfs  noatime,inode64 0 0

The Young Contender: btrfs

Pronounced “Butter F S” or “Bee Tree F S”—I don’t have time for that debate—btrfs is the Swiss Army knife. It’s not just a filesystem; it’s a storage management platform. Its killer features are copy-on-write (CoW), built-in RAID, and subvolumes.

CoW means when you modify a file, the data is written to a new block on disk first, and only then is the pointer updated. This prevents a whole class of corruption from power loss and is the foundation for its fantastic snapshot feature. Want to try a risky system update? Snapshot your root filesystem first. It blows up? Reboot and revert. It’s like a time machine.

Subvolumes are like partitions within a partition, but far more flexible. You can have your /, /home, and /var all on one btrfs partition as separate subvolumes, each with its own snapshot policy.

# Create a btrfs filesystem
sudo mkfs.btrfs /dev/sdb1

# Mount it
sudo mount /dev/sdb1 /mnt

# Create a subvolume (think of it like a special directory)
sudo btrfs subvolume create /mnt/@home

# Create a read-only snapshot of that subvolume
sudo btrfs subvolume snapshot -r /mnt/@home /mnt/@home_backup

The catch? btrfs has a… complicated history. Its RAID 5/6 implementation was famously buggy for years (and many still consider it unstable). It can also feel more complex to manage when things go wrong. But for a desktop or a non-mission-critical system, its snapshotting is a game-changer for reliability.

The Beast from Beyond: ZFS

ZFS is the 800-pound gorilla that came from Solaris. It’s not just a filesystem; it’s a volume manager and filesystem fused into one glorious, feature-packed whole. It does everything: incredible data integrity (checksumming everything), copy-on-write, snapshots, built-in RAID-Z (a superior software RAID), and mind-boggling scalability.

Its integrity is its crown jewel. It checksums all data and metadata, so it can detect and self-heal silent data corruption if you have a redundant setup (e.g., a mirror or RAID-Z). This is a feature the others largely lack.

The big, glaring, absurd caveat? Licensing. ZFS is licensed under the CDDL, which is incompatible with the GPL. This means it can’t be included in the mainline Linux kernel. So on most distros, you’re either using DKMS to compile it every time your kernel updates or relying on a third-party repo. It’s a legal and logistical mess, which is a shame because the tech is phenomenal.

# On Ubuntu, you'd install it first
sudo apt install zfsutils-linux

# Create a pool (ZFS's term for a combined volume/filesystem). This creates a mirror.
sudo zpool create mypool mirror /dev/sdb /dev/sdc

# Now you have a filesystem mounted at /mypool. Want a new sub-filesystem?
sudo zfs create mypool/home

# Take a snapshot
sudo zfs snapshot mypool/home@backup

So, which one do you pick?

  • Just want it to work and not think about it? ext4.
  • Need raw throughput on a large single volume? XFS.
  • Want awesome snapshotting for a desktop or dev server? btrfs.
  • Building a data integrity-critical NAS and aren’t afraid of licensing headaches? ZFS.

There is no single right answer, only the right answer for your specific problem. Choose wisely.