What if the drive holding ten years of family photos quietly flipped a few bits and nobody noticed for months? That is the question that separates Btrfs and ext4, the two filesystems most people meet when they set up a NAS. Both are mature, both are fast enough for a home or small office box, and both ship on mainstream Linux. Yet they fail in very different ways, and the choice shapes what your NAS can do for the next five years.
This comparison sticks to what is verifiable from kernel documentation, vendor behavior, and real-world deployment patterns. No benchmark theater, no “one filesystem to rule them all” claims. Just the trade-offs that matter when you are standing in a store aisle or clicking “create volume” in a web interface.
What Each Filesystem Actually Is
ext4 is the fourth generation of the extended filesystem family. It was declared stable in the Linux kernel in 2008 (kernel 2.6.28, December 2008), replacing ext3, and it has been the default on most Linux distributions ever since. It is a journaling filesystem: it logs metadata changes before committing them, which keeps the structure consistent after a crash. What it does not do is checksum your file data or take snapshots.
Btrfs (B-tree filesystem) was merged into the mainline kernel in 2009 (kernel 2.6.29, March 2009). It was labeled experimental for years, and that label was removed around kernel 5.x, commonly cited as 5.0 in 2019. Some kernel maintainers still push back on the idea that every feature is production-ready, especially RAID5/6. Btrfs is a copy-on-write filesystem: new data is written to new blocks rather than overwriting old ones, which is what enables snapshots, checksums, and built-in RAID.
The practical difference in one sentence: ext4 stores your data and keeps the structure tidy; Btrfs stores your data, checks it, versions it, and can heal it from a redundant copy.
| Feature | ext4 | Btrfs |
|---|---|---|
| First stable in kernel | 2008 (2.6.28) | 2009 (2.6.29), experimental label removed around 5.0 |
| Data checksums | No | Yes, per block |
| Snapshots | No native support | Yes, near-instant via CoW |
| Built-in RAID | No (needs mdadm/LVM) | Yes, including RAID0/1/10 and RAID5/6 |
| Data scrub | No equivalent | Yes, verifies checksums and repairs from a good copy |
| Online grow | Yes | Yes |
| Online shrink | Limited, generally offline | Yes |
| Typical CPU/RAM overhead | Lower | Higher due to checksumming and CoW |
Data Integrity: Where Btrfs Pulls Ahead
Hard drives lie. A sector can return data without an error flag, and the filesystem has no way to know the bits changed. This is silent data corruption, sometimes called bit rot, and it is the single strongest argument for Btrfs on a NAS.
Because Btrfs stores a checksum for every block of data and metadata, a scrub reads the stored data, recomputes the checksum, and flags any mismatch. If the volume has redundancy (RAID1 or RAID10), Btrfs can pull a good copy from the mirrored device and rewrite the damaged block. ext4 has no equivalent mechanism. It will happily serve corrupted bytes because it never recorded what the bytes were supposed to be.
That said, ext4 is not reckless. Its journal protects metadata consistency, and on a single-drive NAS with no redundancy, checksums can detect corruption but cannot repair it. Detection still matters: you learn which file is damaged and can restore it from backup instead of discovering the problem years later.
The honest caveat is that integrity features only pay off if you actually run scrubs on a schedule and keep backups. A Btrfs volume that is never scrubbed is only marginally safer than ext4 in daily use.
Snapshots, Rollback, and the Backup Trap
Snapshots are the feature most NAS buyers underestimate. On Btrfs, a snapshot is nearly free at creation time because copy-on-write means the new snapshot just references existing blocks. Changed blocks get copied later. That makes it practical to keep hourly or daily snapshots of a shared folder without doubling storage use.
This is exactly why vendors adopted Btrfs. Synology’s DSM uses Btrfs on many mid-range and high-end models specifically to enable snapshots and data scrubbing, while entry-level models stick with ext4. The vendor documentation varies by model and firmware version, so check the spec sheet for the exact unit rather than assuming. (Btrfs documentation)
Here is the trap: a snapshot is not a backup. Snapshots live on the same volume as the original data. If the drive dies, the pool is destroyed, or ransomware encrypts the volume, the snapshots go with it. Snapshots protect against accidental deletion and unwanted changes, not against hardware failure. A real backup lives on a different device, ideally in a different building.
ext4 users are not locked out of versioning. Many NAS platforms layer their own snapshot systems on top, and file-level versioning in the vendor’s software can cover the common cases. But the filesystem itself offers nothing, so you depend entirely on the vendor’s implementation.
Performance and Resource Cost in Practice
Benchmarks for Btrfs versus ext4 are notoriously unstable. Results swing with kernel version, mount options, workload type, and whether compression is on. Anyone quoting a single “Btrfs is 20% slower” number without those details is selling something.
What can be said with confidence: ext4 has lower CPU and RAM overhead and generally performs well on metadata-light workloads. Btrfs pays for checksumming and copy-on-write with CPU time, and CoW can cause fragmentation on workloads that rewrite files in place, such as virtual machine images or busy databases. Modern kernels have improved this considerably, and disabling CoW for specific directories is a common fix.
For a home NAS serving media, documents, and backups, both filesystems saturate a gigabit link easily. On 2.5GbE or 10GbE with many small files, differences show up, but they are rarely the bottleneck compared to drive speed and network hardware. The practical guidance: benchmark your own workload if performance is critical, and do not pick a filesystem based on someone else’s synthetic test from three years ago.
RAM matters more than people expect. Btrfs benefits from memory for its metadata cache, and scrub jobs are I/O intensive. A NAS with 1GB of RAM will feel the difference; 4GB or more makes it a non-issue.
RAID5 and RAID6: The Warning Worth Heeding
Btrfs includes built-in RAID, which sounds like a gift until you read the fine print. RAID5 and RAID6 in Btrfs have a long-standing write hole problem, and the upstream documentation has historically warned against using them in production. The write hole is a window where a power loss during a partial stripe write can leave parity inconsistent, and recovery becomes unreliable.
The safe configurations are RAID1 and RAID10, which mirror data and let Btrfs repair from a good copy during scrub. If you want parity RAID, the conventional advice is to use mdadm or LVM underneath ext4, or move to a ZFS-based system, rather than trusting Btrfs RAID5/6.
ext4 sidesteps this entirely because it does not implement RAID itself. You build the array with mdadm, format ext4 on top, and the filesystem stays simple. That simplicity is a feature: fewer layers, fewer surprises, and a recovery story that generations of administrators already know.
Converting, Growing, and Living With Your Choice
Btrfs can be converted in place from ext4 using `btrfs-convert`, and the upstream documentation has long cautioned that conversion is not a substitute for a backup. Rollback support has been limited, and a conversion gone wrong on a full drive is a bad day. If you want Btrfs, the cleaner path is to back up, reformat, and restore. (Btrfs)
Both filesystems support online growth, so adding a larger drive to a pool or expanding a volume does not require downtime in most setups. Shrinking is where they diverge: ext4 shrink is generally an offline operation with limited online support, while Btrfs supports online shrink. Most NAS users never shrink a volume, so this rarely decides anything.
Distribution defaults offer a useful signal. Fedora has used Btrfs as its default since Fedora 33 (October 2020). Most other mainstream distributions still default to ext4, which tells you that ext4 remains the conservative, universally supported choice.
A Practical Decision Framework
Choose ext4 when:
- You want maximum compatibility and the simplest recovery path.
- The NAS is a single-drive box where checksums cannot repair anything anyway.
- You run parity RAID through mdadm or the vendor’s own layer.
- The hardware is low on RAM and CPU, such as an older or entry-level unit.
- You rely on the vendor’s own snapshot and versioning software.
Choose Btrfs when:
- You plan to use RAID1 or RAID10 and want scrub-based self-healing.
- Snapshots of shared folders are part of your workflow.
- The NAS has enough RAM (4GB or more is comfortable).
- You will actually schedule scrubs and keep separate backups.
- You are avoiding Btrfs RAID5/6 and know why.
Mistakes people make
The most common error is treating snapshots as backups. The second is enabling Btrfs RAID5 because it sounds efficient, then discovering the write hole warning after the array is full. The third is skipping scrubs entirely, which leaves the integrity features dormant. The fourth is converting ext4 to Btrfs without a verified backup. And the fifth is choosing based on a benchmark that tested a different kernel, different drives, and a different workload than yours.
A sensible routine for either filesystem: keep at least one backup on separate hardware, test a restore once a year, monitor drive health with SMART data, and document what you configured so future-you is not guessing.
Conclusion
There is no universal winner in the NAS Btrfs vs ext4 question, only a fit between filesystem and job. ext4 is the dependable workhorse: simple, fast enough, low overhead, and easy to recover. Btrfs is the feature-rich option: checksums, snapshots, scrubs, and self-healing mirrors, paid for with more CPU, more RAM, and a shorter list of safe RAID modes. If your NAS holds data you cannot recreate and you have redundancy plus backups, Btrfs earns its keep. If you want predictability and a single drive, ext4 will serve you quietly for years. Match the tool to the job, and either choice will treat you well.
Frequently Asked Questions
Is Btrfs still experimental?
No, the experimental label was removed around kernel 5.0 in 2019. However, some kernel maintainers still advise caution for specific features, most notably RAID5 and RAID6, which have a long-standing write hole problem. Treat Btrfs as production-ready for RAID1 and RAID10, and treat parity RAID as a feature to avoid.
Does ext4 protect against bit rot?
Not by itself. ext4 has no data checksums, so silent corruption goes undetected by the filesystem. It protects metadata consistency through journaling, which is a different guarantee. If bit rot detection matters, you need Btrfs, ZFS, or another checksumming layer.
Can I convert ext4 to Btrfs without losing data?
The `btrfs-convert` tool exists, but upstream documentation has long cautioned that conversion is not a substitute for a backup, and rollback support has been limited. The safer route is to back up, reformat as Btrfs, and restore. Never convert a volume that holds the only copy of your data.
Is Btrfs slower than ext4?
It depends heavily on kernel version, mount options, workload, and whether compression is enabled. ext4 generally has lower CPU and RAM overhead, while Btrfs pays for checksumming and copy-on-write. For typical home NAS use over gigabit Ethernet, both are fast enough that the network is the bottleneck.
Which filesystem does Synology use?
Synology’s DSM uses Btrfs on many mid-range and high-end models to enable snapshots and data scrubbing, while entry-level models use ext4. The exact cutoffs vary by model and firmware, so check the specification sheet for the specific unit rather than assuming.
Do snapshots replace backups?
No. Snapshots live on the same volume as the original data, so they disappear if the drive fails or the pool is destroyed. They protect against accidental deletion and unwanted changes. A real backup sits on separate hardware, ideally off-site, and gets tested with a restore.
