Learn RAID - ZFS RAIDZ (dRAID, AnyRaid)

#Introduction

Up to episode 7, we worked at the block device level with mdadm. Episode 8 opens a new dimension: RAID inside a filesystem. ZFS brings the RAIDZ concept that combines storage management, checksums, and snapshots in a single layer — and this is why many modern admins move from hardware RAID to ZFS.

Why does this matter? Because RAIDZ isn't just a way to combine disks. It delivers data integrity: every block is checksummed, every read is verified, and every failure is detected before it can damage data. In this episode you'll understand why ZFS rejects the mdadm-plus-RAID-5 combination, and how RAIDZ1/2/3 work. Let's start with the foundation.

One note before continuing: ZFS is a filesystem, not merely an array-building tool. That's why its rules differ from mdadm — for example, you can't mix disks of very different sizes in one vdev without losing efficiency. This concept may feel foreign if you're used to working at the block device level, but it will make sense once you see how ZFS manages data as a whole.

#Why ZFS Doesn't Use mdadm with RAID 5

#The Non-atomic Parity Write Problem

The combination of mdadm and RAID 5 is known for the write hole: when power fails in the middle of writing a stripe, some data and parity blocks can fall out of sync. Because mdadm doesn't record the write order, after a reboot the array "looks" clean even though the data is silently corrupted.

ZFS closes this hole with a strict write order: data is always written first, checksums are computed, and then parity is calculated from data that is already consistent. There's no window where parity can drift from the data. This is one of the fundamental reasons ZFS is safer for parity RAID.

#Checksums and Self-healing

On top of that, ZFS stores a checksum for every block. When ZFS reads a block and finds a mismatch, it knows exactly which block is damaged. If there's a mirror or parity disk that can recalculate it, ZFS repairs the block automatically — a concept called self-healing. mdadm can't do this because it doesn't store checksums.

#RAIDZ1, RAIDZ2, RAIDZ3

#Creating a RAIDZ Pool

RAIDZ is ZFS's answer to parity. The number after it indicates the parity count: RAIDZ1 has one parity, RAIDZ2 has two parity disks, RAIDZ3 has three.

sudo zpool create tank raidz1 /dev/sdb /dev/sdc /dev/sdd
zpool status tank

The zpool create tank raidz1 command creates a pool named tank from three disks. The zpool status tank output shows config: with a raidz1 vdev and all disks reporting ONLINE.

#Capacity and Overhead

RAIDZ capacity follows the same rules as conventional RAID: RAIDZ1 leaves N-1 capacity, RAIDZ2 leaves N-2, RAIDZ3 leaves N-3. However, there's an important rule: ZFS recommends a balanced number of disks and rejects RAIDZ vdevs that are too small.

#Choosing a Level

• RAIDZ1: economical, good for data that can be replicated elsewhere.
• RAIDZ2: the standard for important data — survives two simultaneous disk failures.
• RAIDZ3: for very large arrays or highly valuable data.

#RAIDZ Expansion and dRAID

#RAIDZ Expansion

One of RAIDZ's historical limitations was that you couldn't add disks to an existing vdev. The RAIDZ expansion feature — stable in OpenZFS 2.3 and mature in 2.4 — changes this. Now you can add a single disk to a RAIDZ vdev:

sudo zpool attach tank raidz1-0 /dev/sde
zpool status tank

The zpool attach tank raidz1-0 /dev/sde command adds /dev/sde to the vdev and starts redistributing data. The process is gradual and can take a long time, but it requires no downtime.

#dRAID: Declustered RAID

dRAID is a RAIDZ variant that distributes parity and data more evenly using distributed spares. The advantage: during a rebuild, the work is spread across all disks instead of just a few, so the rebuild is much faster and disk pressure is more balanced. It's ideal for large storage with many disks:

sudo zpool create draid-pool draid2:4d:1s /dev/sdb /dev/sdc /dev/sdd /dev/sde /dev/sdf
zpool status draid-pool

The draid2:4d:1s syntax means two parity disks, four data disks, and one logical spare spread across them. dRAID is mature in OpenZFS 2.4 and has become the primary choice for storage racks with dozens of disks.

#AnyRaid and the Final Comparison

#AnyRaid in OpenZFS 2.4

AnyRaid is a new feature in OpenZFS 2.4 that frees you from RAIDZ's rigid rules: you can now design parity and data topologies flexibly — for example, spreading data across more disks than parity requires. It bridges RAID 10-like flexibility with RAIDZ efficiency:

zpool version

The zpool version output must show a valid ZFS version. AnyRaid, RAIDZ expansion, and dRAID all require OpenZFS 2.4 or later — make sure your distro or repository already provides it.

#When to Choose What

• RAIDZ1/2: 3 to 10 disks, important but not critical data.
• RAIDZ3: 11+ disks or highly valuable data.
• dRAID: 16+ disks, prioritizing fast rebuilds and even distribution.
• AnyRaid: non-standard topologies that need design flexibility.

#Conclusion

Episode 8 introduced the ZFS RAID ecosystem: RAIDZ1/2/3 that's safe from the write hole thanks to checksums, RAIDZ expansion for adding disks, dRAID for large storage with fast rebuilds, and AnyRaid for flexible topology design in OpenZFS 2.4.

Key takeaways:

• ZFS closes the RAID 5 write hole through write ordering and per-block checksums.
• RAIDZ1, RAIDZ2, RAIDZ3 are parity with N-1, N-2, N-3 capacity.
• Checksums and self-healing let ZFS detect silent corruption.
• RAIDZ expansion adds disks to a vdev without rebuilding.
• dRAID distributes spares and speeds up rebuilds on large arrays.
• AnyRaid gives you freedom in designing parity and data topologies in OpenZFS 2.4.

In the next episode, episode 9, we'll discuss RAID 10 & performance workloads — why mirror-plus-stripe is a favorite for databases and VMs, how to calculate IOPS, and when to choose RAID 10 over RAIDZ or RAID 6. You'll learn to design storage for demanding workloads.