Filesystems for RAID — The Complete Guide
Choosing the right filesystem for your RAID array is just as important as choosing the RAID level itself. ZFS, Btrfs, ext4, and XFS each bring different trade-offs in integrity, performance, scalability, and features. This guide breaks down everything you need to know.
ZFS — The Gold Standard for Data Integrity
ZFS (originally developed by Sun Microsystems for Solaris, now maintained as OpenZFS on Linux and FreeBSD) is widely regarded as the most advanced filesystem available for RAID storage. Its integrated volume manager and a rich feature set make it a compelling choice for everything from home NAS appliances to enterprise storage arrays.
Self-Healing Checksums
Every data block and metadata block in ZFS is protected by a 256-bit checksum (configurable between Fletcher-2, Fletcher-4, and SHA-256). When data is read, ZFS verifies the checksum against the stored value. On a RAID-Z or mirrored vdev, if a checksum mismatch is detected, ZFS automatically reads the correct data from a redundant copy, rewrites the corrupt block, and reports the error — all transparently. This self-healing capability is unique to ZFS (and partially Btrfs) among mainstream filesystems.
Copy-on-Write Eliminates the Write Hole
ZFS uses a copy-on-write (CoW) transaction model. When data is modified, ZFS writes the new data to a fresh block rather than overwriting the old one in place. The metadata tree is updated atomically via uberblock rotation. This means a power loss or system crash during a write can never leave a RAID stripe in a partially-written state — the so-called RAID write hole (explained in detail below) simply cannot occur. For RAID 5/6/RAID-Z configurations this is a critical advantage.
ARC Caching
The Adaptive Replacement Cache (ARC) is ZFS's in-memory read cache. It intelligently balances between frequently accessed (MFU) and recently accessed (MRU) data, adapting to workload patterns far more effectively than the Linux page cache. A second-level cache (L2ARC) can be added using a dedicated SSD to extend the cache pool. For RAID arrays serving mixed workloads, the ARC dramatically reduces latency for hot data.
Snapshot Performance
ZFS snapshots are instantaneous and nearly space-free at creation — they record a reference to the current dataset state without copying any data. Subsequent writes to the active dataset trigger CoW, preserving the snapshot's view of older blocks. Snapshots can be replicated incrementally with zfs send /zfs recv, making remote backup efficient even across large datasets.
Expansion Limitations
Historically, ZFS RAID-Z vdevs could not be expanded by adding a single disk — you had to add an entire vdev (e.g., another 6-disk RAID-Z2) or migrate data. The 2024 OpenZFS feature calledRAID-Z Expansion has changed this: you can now add one disk at a time to an existing RAID-Z vdev and have data reshuffled in place. The process is linear and can take hours or days on large arrays, but it does not require an off-line data migration. Still, many production administrators prefer to plan vdev layout carefully upfront.
Btrfs — Feature-Rich but Complex
Btrfs (B-tree File System, often pronounced "butter FS") is a modern CoW filesystem for Linux developed primarily by Oracle, Facebook, and other open-source contributors. It offers many of the same high-end features as ZFS — checksums, snapshots, compression, and built-in RAID — but with native Linux kernel integration.
Copy-on-Write and Snapshots
Like ZFS, Btrfs uses a copy-on-write B-tree architecture that provides instantaneous snapshots and subvolume management. Subvolumes are independent POSIX file namespaces within a single Btrfs filesystem — they can be snapshotted, rolled back, and even mounted separately. This makes Btrfs excellent for container storage (Docker, Podman) and system rollback scenarios (e.g., Fedora's default Btrfs layout on root).
RAID 5/6 Status — Still Has Issues
Caution: Btrfs RAID 5/6
As of 2026, Btrfs RAID 5 and RAID 6 are not considered fully production-safe. Known issues include parity corruption after power loss (write hole), write-hole scenarios during degraded operation, and potential data loss during scrubs. For non-critical or experimental setups these modes may be acceptable, but for production data ZFS or mdadm+ext4/XFS remain strongly preferred.
Btrfs RAID 0, RAID 1, and RAID 10 are considered stable and widely used. The single-profile (no redundancy) and dup-profile (metadata duplicated) modes are also production-ready. The ongoing Btrfs development community has made incremental improvements to RAID 5/6 parity management, but the consensus among storage engineers is that the parity RAID modes still lag behind ZFS and mdadm in reliability.
Subvolumes and Snapshots
Btrfs subvolumes are a first-class concept: a single Btrfs filesystem can host many subvolumes, each with independent CoW semantics, quotas, and snapshot schedules. Snapshots can be read-write or read-only. Read-only snapshots are the basis for incremental send/receive (similar to ZFS replication). Btrfs send/receive is widely used in backup solutions like Snapperand btrbk.
Scrubbing and Self-Healing
The btrfs scrubcommand reads all data and metadata blocks, verifies checksums, and repairs corrupted blocks from a redundant copy when available. This is directly analogous to ZFS scrubbing. The scrub operates online (the filesystem stays mounted and active) and can be scheduled via cron or systemd timers. However, Btrfs self-healing only works reliably in RAID 1/10 profiles; in RAID 5/6 the healing capability is still considered fragile.
ext4 — The Tried-and-True Workhorse
The Fourth Extended Filesystem (ext4) has been the default Linux filesystem for over a decade. It is mature, performant, and exceptionally well-tested across every imaginable workload. When paired with mdadm (Linux software RAID), ext4 forms the most battle-hardened combination in the Linux ecosystem.
Journaling
ext4 uses journaling to protect metadata consistency. The journal records pending metadata changes before they are applied; after a crash, the journal is replayed to bring the filesystem to a consistent state. ext4 supports three journaling modes: journal (all data and metadata journaled — safest but slowest), ordered (metadata journaled, data written first — default), and writeback (metadata journaled, no data ordering). Ordered mode provides a good balance of safety and performance for most RAID deployments.
No Checksumming for Data
Limitation: No Data Checksums
ext4 does not checksum user data blocks. Only the journal (metadata) is checksummed. This means silent data corruption — bit rot from media degradation, phantom writes, or read-disturb faults — will not be detected at the filesystem level. The RAID layer (mdadm) can report "read errors" when a sector is unreadable, but it cannot detect corruption where data is still readable but wrong.
If data integrity is paramount, you can layer dm-integrity orLUKS2 with integrity underneath ext4 to provide checksumming, but this adds complexity and performance overhead. For many bulk-storage workloads (media servers, backup targets with their own checksum tools like restic or Borg), ext4's lack of built-in checksumming is an acceptable trade-off.
Widely Supported on mdadm RAID
The ext4 + mdadm combination is the most documented and supported Linux storage stack. Every major Linux distribution has battle-tested tools for creating, resizing, and repairing ext4 filesystems on mdadm arrays. Online resizing (add space to the filesystem after expanding the array) is straightforward: you grow the md array, then runresize2fs. File-system-level defragmentation (e4defrag) and debug tools (debugfs) are mature.
XFS — Built for Scale
XFS is a high-performance 64-bit journaling filesystem created by Silicon Graphics (SGI) in 1993. It was designed for parallel I/O and large files, making it a strong candidate for RAID arrays that serve video, large databases, or high-throughput archival storage.
Good for Large Files
XFS uses extent-based allocation and B-tree indexing for free space and inodes. It excels at workloads with large files (GBs to TBs) and sequential I/O patterns. The maximum filesystem size is 8 exabytes (on a 64-bit system), and maximum file size is 8 exabytes — effectively unlimited for current hardware. Large striping groups allow XFS to align allocations with RAID stripe geometry for optimal performance.
Online Defragmentation
XFS supports online defragmentation via xfs_fsr(Filesystem defragmenter). Unlike offline defragmentation, this operates on a live, mounted filesystem. For RAID arrays that experience fragmentation over time — common on near-full volumes with many small writes — this is a useful maintenance tool with minimal downtime.
Used by Synology DSM
While Synology DSM primarily uses Btrfs for data volumes (DSM 6.2+), many earlier volumes and some legacy configurations run on ext4. However, for Synology's high-end enterprise units such as the FS/SA/RS series, XFS was historically used as the underlying filesystem before Btrfs became the default. Many enterprise NAS vendors besides Synology also support XFS for its proven scalability and low fragmentation profile.
Checksums and Integrity
Since Linux kernel 5.10, XFS has metadata checksumming (CRC32c) enabled by default on new filesystems (the -m crc=1mkfs option). However, like ext4, XFS does not checksum user data blocks. For data integrity you need either the CoW filesystems (ZFS/Btrfs) or a separate integrity layer.
Feature Comparison Table
A side-by-side comparison of the four major filesystems across the features that matter most for RAID deployments:
| Feature | ZFS | Btrfs | ext4 | XFS |
|---|---|---|---|---|
| Data checksums | ||||
| Self-healing | Partial | |||
| Metadata checksums | ||||
| Snapshots | ||||
| Inline compression | ||||
| Deduplication | Experimental | |||
| Online expansion | RAID-Z (2024+) | |||
| Max volume size | 256 ZiB | 16 EiB | 1 EiB | 8 EiB |
| RAID-native |
"RAID-native" means the filesystem includes integrated RAID functionality without requiring mdadm or hardware RAID. "Online expansion" refers to growing the filesystem onto newly added disk space.
Which Filesystem for Your Workload?
Different workloads place different demands on the filesystem. Here is expert guidance for common scenarios:
Media Server
Recommendation: ZFS or ext4 on mdadm
Media files are large, mostly read-only after ingestion, and tolerant of a corrupt frame or two. ZFS with compression (lz4 or zstd) can reduce storage for mezzanine files significantly. ext4 on mdadm is simpler and performs extremely well for sequential reads. Btrfs is also fine for media if RAID 1/10 is used. Avoid inline dedup — the performance cost rarely benefits media workloads.
Database Server
Recommendation: XFS or ext4 on mdadm
Databases (PostgreSQL, MySQL, MariaDB) perform their own checksumming and crash recovery. The CoW overhead of ZFS and Btrfs can add write amplification and fragmentation under heavy OLTP workloads. XFS excels here with low fragmentation and excellent concurrent write performance. ext4 on mdadm is also proven. If you want ZFS for snapshots, use recordsize=16K and disable atime.
Backup Target
Recommendation: ZFS
For long-term backup storage, ZFS is unmatched. Its checksumming ensures backup data remains intact over years of silent storage. Snapshots enable rapid point-in-time recovery without duplicating data. ZFS send/receive provides efficient incremental replication to off-site targets. Compression (zstd-3) typically saves 20-40% on backup payloads. Combined with RAID-Z2, this is the gold standard for backup repositories.
Virtualization
Recommendation: ZFS or XFS on mdadm
For VM storage (QEMU/KVM, Proxmox, VMware), ZFS offers snapshots, clones, and ARC caching that dramatically accelerate boot storms. Native ZVOLs can serve as raw block devices for VMs with low overhead. XFS on mdadm is the traditional choice for large VM datastores (XFS agglomerations align well with virtual disk files). If using ZFS for VMs, set recordsize=64K and consider log ZIL on separate SSD for synchronous writes.
How Filesystem Choice Affects RAID Rebuild Speed
When a disk in a RAID array fails and is replaced, the array must rebuild — read all data from the surviving disks and reconstruct the missing data onto the replacement. The filesystem layer can significantly impact rebuild performance.
Checksumming Adds Overhead
ZFS and Btrfs verify checksums on every read. During a RAID-Z or Btrfs RAID rebuild, every surviving block is read, checksummed, and verified before being used to reconstruct the replacement. This CPU overhead can slow rebuilds by 10–30% compared to ext4/XFS on mdadm, which simply read blocks without verification. On modern CPUs with hardware CRC32c or SHA-NI instructions, the impact is modest — typically in the single-digit percentage range.
Bit Rot Detection During Rebuilds
The checksumming overhead is a trade-off that pays dividends in data integrity. When ext4 or XFS on mdadm reads a corrupt block during a rebuild, it simply copies the corrupt data to the new disk — the corruption is silently propagated. ZFS, by contrast, detects the checksum mismatch, reads the redundant block from another surviving disk (if available), and writes the correct data to the replacement. This means a ZFS rebuild is not just faster in terms of correctness — it produces a healthy array rather than a silently corrupted one.
Practical Rebuild Speed Guidance
- mdadm + ext4/XFS — Fastest raw rebuild speed. Good for arrays where rebuild time is critical (e.g., large RAID 5 arrays with exposed risk during rebuild).
- ZFS RAID-Z — Slightly slower rebuild (checked checksums) but highest data integrity. Use ashift=12 (4K sector alignment) for optimal performance on modern drives.
- Btrfs RAID 1/10 — Rebuild speed comparable to ZFS. RAID 5/6 rebuilds are slower and less reliable.
- Hardware RAID + ZFS — Avoid. Dual parity layers complicate rebuild and can mask errors.
Regardless of filesystem, always monitor rebuild progress and ensure proactive disk health monitoring (SMART, S.M.A.R.T. long tests) to detect potential secondary failures during the vulnerable rebuild window.
The RAID Write Hole — and How CoW Filesystems Solve It
The RAID write hole is a vulnerability inherent to parity-based RAID levels (RAID 5, RAID 6, and their nested variants). Understanding it is essential for choosing the right filesystem.
What Is the Write Hole?
In RAID 5/6, a single write operation must update both the data stripe on one disk and the parity stripe on another. These writes are not atomic — a power loss or system crash between the two writes can leave the stripe in an inconsistent state where the parity no longer matches the data. This is the write hole. The next time the array degrades and tries to reconstruct data using the stale parity, it produces incorrect (and undetectably corrupt) data.
Write Hole Scenario Example
- Application issues a 4 KB write to a RAID 5 array (3 disks: data + data + parity).
- The RAID controller reads old data and old parity, computes new parity.
- New data is written to disk 1. ✓
- Power loss. New parity is never written to disk 3. ✗
- On power restore: disk 1 has new data, disk 3 has old parity. Stripe is inconsistent.
- Later, disk 2 fails. RAID uses disk 1 data + disk 3 parity to reconstruct disk 2 → corrupt data.
Why CoW Filesystems Eliminate the Write Hole
Copy-on-write (CoW) filesystems like ZFS and Btrfs solve the write hole by never overwriting data in place. Instead:
- The new data and new parity are written to free blocks elsewhere on the disks.
- The metadata tree is updated atomically in a single transaction group
- If a crash occurs mid-write, the old consistent state (data + parity) remains intact.
- On recovery, the partially written transaction is simply discarded — no inconsistency.
This atomic transaction model is why ZFS RAID-Z is considered immune to the write hole, and why Btrfs RAID 1/10 provides similar protection. For traditional filesystems (ext4, XFS) on mdadm, the write hole is mitigated by mdadm's "write intent bitmap" (a journal of pending writes) and by the Linux block layer's flushing semantics, but the protection is not as fundamental as CoW.
Write Hole Protection by Configuration
| Configuration | Write Hole Protected? |
|---|---|
| mdadm RAID 5/6 + ext4/XFS | Partial |
| mdadm RAID 5/6 + ext4/XFS + write-intent bitmap | Partial |
| mdadm RAID 1/10 + ext4/XFS | |
| ZFS RAID-Z / RAID-Z2 / RAID-Z3 | |
| Btrfs RAID 1/10 | |
| Btrfs RAID 5/6 | ⚠ Unreliable |
| Hardware RAID controller with BBU (battery backup) | Mitigated* |
* Hardware RAID with battery-backed cache (BBU) or NV cache can flush pending writes after power restore, mitigating but not eliminating the write hole. The CoW approach provides true immunity.
Frequently Asked Questions
Which filesystem is best for RAID 5?
Can I use ZFS on hardware RAID?
Is Btrfs safe for RAID 5/6 in 2026?
Does ext4 support data checksums?
What filesystem does Synology DSM use?
Can I mix different filesystems in the same RAID array?
Ready to Build Your RAID Array?
Now that you know which filesystem suits your workload, head over to our RAID Calculator to plan your disk layout, estimate usable capacity, and compare RAID levels side by side.
Open RAID CalculatorThis guide is maintained by the StashRaid team. Found an error or want to suggest an update?Contact us.
Last updated: July 2026. Always verify filesystem compatibility with your kernel version.