Learn Linux Filesystem - Filesystem Selection Guide

#Introduction

After 17 episodes studying each filesystem in depth, episode 18 answers the most practical question: which one should I choose? There's no universal answer — only a decision framework that weighs workload, team, and support realities.

This episode builds a selection guide for ext4, XFS, btrfs, ZFS, and tmpfs. Then we discuss the trade-offs that are often overlooked: feature costs, ZFS RAM overhead, and vendor support politics. In the end you'll get a checklist you can run in real projects.

Remember the principle from episode 10: match the filesystem to the workload, not the other way around.

#Profile of Each Filesystem

#ext4: The Versatile Choice

ext4 is the default on Ubuntu and Debian — the most battle-tested and simplest filesystem.

Good for:

• Root filesystems and general-purpose servers.
• Medium database loads with minimal tuning.
• Teams that want storage without surprises.

Not ideal for:

• Native snapshot and compression needs.
• Multi-petabyte filesystems.

Its greatest advantage is simplicity: complete documentation, well-understood recovery, and near-zero CPU/RAM overhead.

#XFS: High Throughput

XFS is the default on RHEL, Rocky, and AlmaLinux — designed for large files and parallel loads.

Good for:

• Media servers, backups, and archives.
• Loads with many large files.
• Environments already based on Red Hat.

Not ideal for:

• Native snapshot needs (it doesn't have them).
• Online shrinking (it can't shrink).

#btrfs: Kernel-Built-in Snapshot and COW

btrfs is the openSUSE default — bringing snapshots, compression, and checksums into the kernel.

Good for:

• Systems updated frequently (snapshot rollback).
• Container storage with COW.
• Transparent zstd compression.

Not ideal for:

• RAID5/RAID6, still experimental.
• Environments requiring Red Hat vendor support (deprecated since 2024).

#ZFS: Integrity and Pools

ZFS is the choice of TrueNAS and enterprise storage — integrity, pools, and RAIDZ in one package.

Good for:

• Critical storage with checksums and self-healing.
• Multi-disk pools with RAIDZ or mirrors.
• Strong deduplication and compression.

Not ideal for:

• Environments with limited RAM (ARC can consume a lot of memory).
• Systems with strict licensing policies (GPL/CDDL).

#tmpfs: Fast RAM

tmpfs stores everything in RAM and swap:

Good for:

• Temporary files, caches, and sockets.
• /dev/shm and ephemeral containers.

Not ideal for:

• Data that must survive a reboot.

#Trade-offs Often Overlooked

#Features vs Simplicity

Every feature is an operational cost. ZFS with snapshots, dedup, and ARC is the strongest filesystem — but also the most complex to operate and debug. The "boring" ext4 is valuable precisely because anyone can manage it.

The honest question to ask: who will be operating this storage for the next three years? If the answer isn't a ZFS expert, consider simplicity.

#ZFS RAM Overhead

ZFS's ARC (Adaptive Replacement Cache) uses system RAM dynamically, often reaching half the total memory on large servers:

arcstat

The size value shows the RAM used by ARC. Set a limit:

echo 8589934592 | sudo tee /sys/module/zfs/parameters/zfs_arc_max

Remember: RAM used by ARC isn't wasted — it's a cache that speeds up reads. But servers running other memory-hungry workloads must set a limit.

#Vendor Support and Licensing

Two political realities that influence choice:

• btrfs on Red Hat: deprecated since RHEL 9.4 — Red Hat no longer recommends it and has removed its documentation. RHEL-based enterprises should avoid it.
• ZFS and licensing: the ZFS kernel module is licensed under CDDL, incompatible with GPL. Distributions like Debian accommodate it via DKMS, but Red Hat doesn't distribute it officially. This is why ZFS has never become a default on mainstream distros.

The practical consequence: filesystem choice is sometimes determined by the ecosystem, not purely by technology.

#The Decision Framework

#The Selection Flow

Use this multi-level flow:

butuh snapshot native? → ya: btrfs / ZFS
   → butuh pool & RAIDZ? → ya: ZFS
   → bukan: btrfs
butuh throughput besar? → ya: XFS
kebutuhan umum / root / sederhana → ext4
data sementara di RAM → tmpfs

Three main questions:

1. Do you need snapshots, checksums, or compression? (points to btrfs/ZFS)
2. Do you need multi-disk pools and RAIDZ? (points to ZFS)
3. Does the workload demand high throughput? (points to XFS)

#Validating with Benchmarks

Don't choose based on opinion — measure on the real workload. Replay your application's write traces with fio:

fio --name=uji --rw=randwrite --bs=8k --iodepth=16 --size=2G --direct=1 --runtime=60 --time_based

Run the same benchmark on ext4, XFS, btrfs, and ZFS (with the recordsize matching the workload), then compare. Data is more convincing than brochures. Use fio --name=uji --rw=randwrite --bs=8k as the same baseline on all filesystems so the comparison is fair.

#Conclusion

Choosing a filesystem is a decision weighing technology and people: the workload determines the need, the team determines the manageable complexity, and the ecosystem determines available support. There's no perfect choice — only the best fit.

Key takeaways:

• ext4 for simplicity and stability; XFS for high throughput.
• btrfs for snapshot + COW + kernel-built-in compression.
• ZFS for integrity, pools, and RAIDZ; tmpfs for temporary data in RAM.
• ZFS ARC uses large amounts of RAM — set zfs_arc_max as needed.
• btrfs is deprecated by Red Hat; ZFS is CDDL-licensed via DKMS.
• Validate your choice with benchmarks on the real workload, not opinions.

In the next episode, episode 19, we cover cloud and managed storage — the difference between instance stores and EBS/gp3, filesystems for cloud images, S3-compatible object storage, and EFS, Azure Files, and GCP Filestore. You'll learn when to use local storage and when to use managed services.