RAIDZ Calculator

Computes usable capacity, parity overhead, storage efficiency, and fault tolerance for a ZFS pool built from RAIDZ1, RAIDZ2, RAIDZ3, dRAID, mirror, or stripe vdevs, with hot spares and dRAID distributed spares included. It splits the pool into slices that add up to every drive you bought: usable space, parity, the ZFS slop and metadata reservation, an optional OS reserve, and spare capacity, which is what the capacity pie draws. It also estimates mean time to data loss from a drive MTBF or annualized failure rate plus your resilver time, and it can simulate individual drive failures so you can see which vdev degrades and where the pool loses data. Decimal (TB, GB) and binary (TiB, GiB) disk sizes are both handled, so you can match the units your drives or your OS actually report.

Set the disks per vdev, the size and unit of each disk, the level, and how many identical vdevs the pool stripes together. Toggle the ZFS overhead estimate, add an OS reserve percent, and add spare drives to watch each one move the capacity pie. For the reliability rows, enter a drive MTBF in hours or an annualized failure rate, plus how long a resilver takes; click a drive in the pool diagram to fail it and the health propagates from drive to vdev to pool. You can still type a shorthand like "6x4TB raidz2" instead of setting the first few options by hand.

Generic RAID calculators treat every array the same, ignore how ZFS reports capacity, and stop at a single usable number, so they cannot tell you whether raidz2 with a hot spare beats raidz3 without one. This one shows the whole breakdown, models dRAID distributed spares, and puts a mean time to data loss estimate next to the capacity so the tradeoff is visible in one place. It is also upfront about its limits: the overhead figure is an approximation, unrecoverable read errors are ignored, and the reliability math assumes drives fail independently at a constant rate.

Why is my real usable space lower than what this shows?

ZFS reserves slop space, spends metadata on padding, and its effective block size interacts with ashift and recordsize in ways a generic calculator cannot model. Capacity reporting has also changed across OpenZFS versions and depends on compression and pool history. Treat this tool's number as a close estimate, not the exact figure zpool list will print.

Should I use raidz1, raidz2, or dRAID?

raidz1 tolerates one disk failure per vdev and wastes the least capacity, but on large drives a second failure during a long resilver can lose the vdev. raidz2 tolerates two failures per vdev and is the common recommendation once drives pass a few terabytes. dRAID trades a little capacity for distributed spare space, which lets a rebuild start with no human involved and finish far faster, so it earns its keep on wide vdevs with many drives.

What does the MTTDL number actually mean?

It is the standard Markov approximation: given a per drive MTBF (or an annualized failure rate, converted with MTBF = 8766 / ln(1 / (1 - AFR))) and how long a repair takes, it estimates the average time until a vdev loses more drives than its parity covers. Use it to compare layouts, not to predict a date. It ignores unrecoverable read errors, assumes drives fail independently at a constant rate, and treats spares as removing the wait for a human rather than adding tolerance. For realistic inputs, Backblaze publishes fleet-wide annualized failure rates and the drive vendors publish lab MTBF ratings on their datasheets.