ZFS vs BTRFS vs EXT4: Filesystem Choices for a NAS

You can buy the best NAS hardware on the market and still lose a weekend of work to the quietest component in the machine. The filesystem has no fan, no beeping, and no driver popup, but it is the one layer you almost never change after the disks fill up, because replacing it means moving every byte. That is why the comparison between ZFS, BTRFS, and EXT4 gets so much airtime on storage forums: people are not choosing a driver, they are choosing the rules their data will live under for the next decade, and they want to get it right before the first drives go in.

Each of the three names answers the same question, how should the disks hold the files, in a genuinely different way. ZFS works as a combined volume manager and filesystem built around checksums, self healing reads, and near free snapshots. BTRFS brings the same copy on write ideas into the Linux kernel with a more flexible hand, and EXT4 is the two decades old baseline that every Linux distribution ships as its default. This guide explains what each one actually does under a NAS workload, where the reputations are deserved, and how to match the filesystem to the box you are building instead of the loudest forum opinion.

At a Glance: ZFS vs BTRFS vs EXT4

What Each Filesystem Actually Is

The three names sit at different layers, and tracing those layers explains most of the practical differences. ZFS is a complete storage stack: the zpool manager creates the virtual device layout, and the filesystem on top of it handles checksums, snapshots, and compression, so the two cannot be separated. BTRFS is the same kind of idea squeezed into the Linux kernel as one filesystem that also manages its own devices, which is why it can stripe or mirror across drives without any extra software. EXT4 is just a filesystem. It expects a partitioning scheme underneath it, and if you want more than one disk, you assemble that yourself with mdadm, LVM, or a hardware RAID card.

That difference cascades into everything else. ZFS makes the storage design decision at pool creation time, and changing it later is deliberate and expensive. BTRFS lets you add a drive and rebalance the data across it with one command. EXT4 leaves the layout puzzle to the tools you stack under it, which means you manage two layers instead of one. On a NAS, the practical consequence is simple: ZFS rewards planning, BTRFS rewards tinkering, and EXT4 rewards knowing the rest of the Linux stack.

ZFS: Checksums, Self Healing, and Pools

ZFS was built at Sun in the mid 2000s to end storage administration, and it shows: every block carries a checksum, every read is verified against it, and when a mirrored or RAIDZ vdev loses a disk, the surviving copies rebuild the missing data automatically. That combination, detect the damage and repair it without asking, is the closest thing storage software has to a superpower, and it is why ZFS is the default answer for anything that says “irreplaceable” on the box. Snapshots are effectively free, replication through zfs send and zfs receive moves a dataset to another machine with checksums intact, and built in compression means audio, video, images, and logs use less space than the drives report.

The price for that armor is rigidity and appetite. ZFS caches aggressively in memory, roughly a gigabyte per terabyte of storage on top of a practical floor of 8 to 16 GB, so a small box with 4 GB of RAM is effectively off the table. Pools grow in whole vdevs or by replacing every disk in a vdev with a larger one, and shrinking is not a supported operation. The licensing history also matters on hardware: ZFS’s CDDL license keeps it out of the Linux kernel proper, so on a stock Debian or Ubuntu install you load it as an out of tree module, while TrueNAS and FreeBSD ship it natively. For a dedicated NAS where the hardware was chosen to suit it, none of this discourages, but it is a commitment, not a curiosity.

Why Data Integrity Is the Real Difference

Once the disk layout conversation is over, one question separates the filesystems more than any benchmark: what happens when a read comes back with corrupted content. A drive can return garbage while reporting perfect health, a parity rebuild over a bad disk can record the damage as truth, and a filesystem that never checks will hand that garbage straight to your client. EXT4 trusts the disk. BTRFS detects the damage. ZFS detects it and repairs it. That three way split is the entire case for a checksumming filesystem on a NAS holding anything you cannot afford to lose.

BTRFS is interchangeable with ZFS on the checksum question, using CRC32C or stronger hashes and a scrub that reads the whole tree looking for inconsistencies, but it depends on a mirror, RAID 1 profile, or a similar redundant layout to repair what it finds. On a single disk it turns the same checksum into an error message rather than a rescue. Below all of that sits EXT4, which trusts what the disk reports, and the disk does not always know. This gap, not speed, is the reason storage veterans push so hard on ZFS or BTRFS for anything holding family photos, documents, or backups: silent bit rot is rare per drive but certain across a shelf of them.

BTRFS: Copy on Write in the Kernel

BTRFS arrived as the Linux answer to ZFS, and on paper the checklists match: copy on write, per file checksums, snapshots, subvolumes, compression, and replication with btrfs send and btrfs receive. Its defining virtue is flexibility. Each drive in a RAID 1 profile keeps its own size, so an 8 TB and a 4 TB disk can mirror without wasting the spare end of the bigger one, a trick mdadm mirrors cannot do. Adding a disk is a btrfs device add followed by a balance, and you can grow or rebalance at will, which makes BTRFS the friendliest of the three when drive sizes drift over the years. openSUSE and Fedora trust it as the default root filesystem, and Synology and QNAP expose it as an option on top of their RAID layers, which means it has been field tested in millions of home boxes.

The honest caveats matter because the filesystem community repeats them constantly. RAID 5 and RAID 6 in BTRFS are still marked unsafe in the docs and can corrupt parity during reconstruction, so the universal advice is to stay on mirrored profiles. The complexity budget is real, too: subvolumes, quotas, and snapshots are concepts you will manage, and forgetting to prune snapshot chains is how a home NAS quietly fills its own disks. And unlike ZFS, nothing fixes a corrupted block without redundancy of some kind, so BTRFS users must pair checksums with a mirror and a scrub schedule. Choose it when you want integrity plus the freedom to change the layout later, and skip it if the word “unsafe” in RAID 5 documentation is enough to keep you awake.

EXT4: The Stable Default

EXT4’s case is the shortest and, for many homes, the most reasonable. It is the filesystem every Linux installer picks by default, it has been in production for approaching two decades, its behavior under crashes and full disks is legendary, and it asks nothing beyond the disk itself. For a single drive share box, or drives pooled under mdadm with LVM on top, EXT4 is quiet, predictable, and fast enough that no NAS user will ever feel the difference at 1 GbE. If your data lives elsewhere safely and the NAS is a convenience shelf, choosing EXT4 means choosing to spend your evenings on other things.

The gap is integrity, and it is the same one every article on this subject comes back to. EXT4 verifies its metadata against a checksum, but the file contents themselves are trusted as read, so a failing drive or a bad cable can deliver silently corrupted files. There is no scrub, no self heal, and no snapshot primitive of its own; you add those by layering LVM snapshots, a different backup tool, or a filesystem that does not need them. It also constrains you to think like a partition manager, because growing or duplicating a disk means working with the mdadm or LVM layer beneath it. Buy a mature directory server for a budget build and you will rarely touch it again, but do not mistake its stability for data protection, because they are different promises.

Adding Capacity Later

The day you buy the NAS, capacity is a fantasy. By the third year it is the emergency. Each filesystem grows differently, and the difference decides how pleasant a future you are buying: ZFS grows by replacing disks in a vdev or adding a whole new vdev, BTRFS accepts any new disk and rebalances, and EXT4 grows the mdadm or LVM layer underneath it. Plan the expansion before the box exists, because this is the point where the three stop being opinions and become architecture.

None of this makes one filesystem better than the others, it makes them better for different plans. If you know the box will double in size in three years and you do not want to think about it, BTRFS is the smoothest ride. If you would rather buy matched disks once and replace them on a schedule, ZFS suits the discipline. If the box is small and cheap and a rebuild is cheap too, EXT4 with mdadm needs no apology. Whatever you pick, buy the next disk with that plan in mind, because the affordable path always follows the filesystem you chose on day one.

How to Choose for Your Own NAS

The decision collapses into one honest question: what is the most valuable thing the box will hold, and how much patience do you have for preservation? If the answer is family photos, documents, or backups of machines that no longer exist, ZFS on TrueNAS or on a Linux install built for it is the strongest free answer, and the RAM and planning it demands are the rent you pay for self healing storage. If the answer is a media library mixed across drives of every age and size, BTRFS gives you integrity without forcing you to buy your drive collection again, and mirrored profiles keep the known BTRFS weaknesses out of reach. If the answer is a scratch NAS for downloads and streaming that would survive losing a disk, EXT4 on top of mdadm or simply as a single drive gives you the cheapest, quietest, most familiar box you can build.

What you should not do is treat the filesystem as a backup plan, because none of the three is one. RAID of any flavor, a mirror, RAIDZ, or a parity array, protects against a dead disk, not against fire, ransomware, or a deleted file, so the rule applies uniformly regardless of which row you end up in: keep a second copy on a different machine, and keep an occasional offline copy you can unplug. That rule is old, it is boring, and it outranks every filesystem argument in this article, because the filesystem that makes corruption a non event still leaves you one deleted parent folder away from a bad evening.

The practical next step after you choose is to decide the maintenance cadence before the box goes live. Pick a day for the ZFS scrub or the BTRFS scrub, set a snapshot and retention schedule you actually understand, and write the layout down somewhere you will find it in two years, because the person debugging the pool at 1 AM is you, and they will appreciate the note. Then install the OS, create the pool or the array, and let the drives earn their keep. The best filesystem is the one you understand, and the best NAS is the one whose rules you would happily explain to another person over coffee.