Modern Filesystems in Practice: Choosing Between Btrfs, ZFS, and bcachefs

Developer Bartosz Fenski recently published a comparison of modern Linux filesystems, focusing on how Btrfs, ZFS, and bcachefs perform under real-world workloads. The article earned 158 points and 152 comments on Hacker News, reflecting ongoing community interest in this topic. Unlike typical synthetic benchmark comparisons, the author deliberately skips those classic, context-free benchmark runs in favor of observing how these filesystems hold up under production-like conditions.

Why Skip Classic Benchmarks

Traditional filesystem evaluations tend to rely on synthetic tools like fio and bonnie++, producing impressive numbers around sequential read/write speeds and random IOPS. The problem is that these numbers are hard to map to what users actually care about — database workloads, heavy small-file operations, and latency behavior when snapshots are being created frequently.

The author's core argument is that synthetic benchmark data is useful for marketing purposes, but offers limited guidance for engineers who need to answer the question: "Which filesystem should I actually use?" Real workloads expose differences in caching strategies, write amplification, and metadata handling that pure benchmarks tend to obscure. That's the intent behind the article's emphasis on skipping "classic benchmarks."

How the Three Filesystems Differ in Design Philosophy

Though often compared side by side, these three filesystems operate at very different levels of maturity and design philosophy.

ZFS: The Battle-Tested Veteran

ZFS originated in Solaris and has years of production validation behind it. It offers end-to-end data integrity verification, Copy-on-Write (CoW), snapshots, compression, and robust storage pool management. In enterprise and NAS environments, ZFS is nearly synonymous with reliability. The trade-offs are a relatively high memory appetite (due to the ARC cache) and an inability to ship directly in the Linux kernel mainline due to license incompatibilities (CDDL vs. GPL) — it's typically installed as a DKMS module.

The ZFS licensing situation is worth unpacking. ZFS was originally open-sourced by Sun Microsystems under the CDDL (Common Development and Distribution License), while the Linux kernel uses GPLv2. The two licenses are considered legally incompatible, preventing ZFS code from being merged directly into the kernel source tree. On Linux, ZFS is distributed primarily through the OpenZFS project as a kernel module, usually installed via DKMS (Dynamic Kernel Module Support), which automatically recompiles the module after each kernel upgrade. This works in practice, but adds maintenance overhead — major kernel version upgrades occasionally create brief compatibility gaps. ARC (Adaptive Replacement Cache) is ZFS's in-memory caching layer; by default, it dynamically claims a significant portion of available system memory. On low-memory machines or in containerized environments, it needs to be manually capped, or it may compete aggressively with other processes.

Btrfs: The In-Kernel Swiss Army Knife

Btrfs has been merged into the Linux kernel mainline for years and requires no extra modules. It also supports CoW, snapshots, subvolumes, and transparent compression. Several distributions — including openSUSE and Fedora — have adopted it as the default filesystem. Historically, its RAID5/6 implementation had well-documented stability issues, a long-standing criticism in the community, but it is considered reliable enough for single-disk and RAID1 configurations.

bcachefs: The Ambitious Newcomer

bcachefs is the youngest of the three, born from the block-layer caching tool bcache. It aims to combine the feature richness of ZFS with the reliability of ext4, while pursuing a cleaner tiered caching architecture. As a relatively recent addition to the kernel, its maturity and ecosystem are still evolving rapidly — it's best suited for users willing to experiment and accept some degree of risk.

Real Differences Under Real Workloads

The value of this article lies in letting workloads — not benchmark scores — do the talking. In Copy-on-Write filesystems, snapshot overhead, fragmentation, and latency under metadata-intensive operations often determine the real user experience far more than sequential throughput does.

For database-style workloads involving frequent random writes, CoW introduces write amplification issues. Both ZFS and Btrfs require targeted tuning (such as disabling CoW or adjusting recordsize/blocksize). bcachefs's tiered caching design theoretically delivers a smoother performance profile in these scenarios, but real-world behavior still needs to be observed over extended operation.

Compression is another underappreciated dimension. Transparent compression is nearly free on modern high-speed CPUs — it saves space, and in IO-bound scenarios may actually improve performance by reducing the volume of data written. All three filesystems support compression, but their default algorithms and tuning options differ.

Write amplification is a key concept for understanding the performance of Copy-on-Write filesystems. The core CoW mechanism works like this: when data is modified, the original block is not overwritten; instead, new data is written to a free location, then metadata pointers are updated. This design is excellent for snapshots and data consistency, but for workloads like databases that frequently update small amounts of data in place, each small write can trigger the reallocation of an entire block — causing actual written data to be several times the logical write volume. Common mitigation strategies include: using chattr +C on database files in Btrfs to disable CoW; aligning ZFS recordsize to the database page size (e.g., 8KB for PostgreSQL); or placing database data directories on a separate partition where CoW features are disabled. bcachefs's tiered caching design can theoretically reduce some of the latency caused by write amplification by keeping hot data on faster storage media, but this requires thoughtful cache tier configuration.

Where the Community Disagrees

The 150+ comments on Hacker News reflect a classic filesystem "holy war." ZFS advocates emphasize its proven stability and data integrity guarantees; Btrfs users value the convenience of native kernel integration; and bcachefs supporters are excited about its architectural design, though some remain skeptical about production readiness for a newer filesystem.

At its core, this divide reflects different risk tolerances: choose ZFS if you prioritize stability, Btrfs if you prioritize convenience, and keep an eye on bcachefs if you're drawn to cutting-edge architecture and can accept some uncertainty. There's no absolute winner — only choices that fit specific needs.

Recommendations for Those Making a Decision

A few practical takeaways emerge from this real-world comparison. If your use case demands the highest data integrity and you can tolerate the extra module overhead and memory consumption, ZFS remains the safe, conservative choice. If you want something that works out of the box with deep kernel integration, Btrfs is mature enough for single-disk and mirrored configurations. If you're a filesystem enthusiast or willing to bet on the future, bcachefs is worth tracking closely.

More importantly, the article's broader lesson is this: when evaluating filesystems, test in an environment that mirrors your actual workload rather than blindly trusting synthetic benchmark numbers passed around by vendors or the community. Your database, your backup strategy, your snapshot frequency — these are the variables that ultimately determine which filesystem is right for you.