ZFS vdev Design Wizard: Capacity, Resilience & Performance
This ZFS vdev design wizard compares mirror, RAIDZ1, RAIDZ2 and RAIDZ3 layouts for a pool of up to 24 drives and recommends one for your workload. It shows the capacity ZFS will report after its slop reserve, which is what TrueNAS shows, next to the nominal capacity and the range your record size gives, plus failures tolerated per vdev, resilver time at your pool fill, and what widening a RAIDZ vdev later would add.
Results are in decimal TB, the unit drives are sold in. It covers mirrors and RAIDZ for small to medium pools; dRAID and QNAP QuTS hero are not modelled. How every figure is worked out, and the OpenZFS, TrueNAS and Unraid documentation behind it, is under How we calculate.
What record size does to this layout
Other layouts for these drives
| Layout | ZFS reports (after slop) | Nominal | Failures | Resilver | Suits |
|---|
Workload fit
Growing this pool later
RAIDZ expansion widens an existing RAIDZ vdev one drive at a time. Data already stored keeps its old data to parity ratio, so the widened vdev holds less than one built at the final width. RAIDZ expansion (adding a disk to an existing RAIDZ vdev) is a feature of OpenZFS 2.3.0. (OpenZFS, checked 2026-10-07)
Worked examples
Capacity in decimal TB at ashift 12. Nominal is (drives minus parity) x drive size for RAIDZ, or one drive per mirror. ZFS reports RAIDZ space as if every block were 128K, then holds back the slop space.
| Drives | Layout | Nominal | ZFS reports | After slop | Failures |
|---|---|---|---|---|---|
| 4 x 12 TB | 2 x 2-way mirror | 24 TB | 24 TB | 23.86 TB | 1 per mirror |
| 4 x 12 TB | RAIDZ1, 4 wide | 36 TB | 34.88 TB | 34.74 TB | 1 |
| 4 x 12 TB | RAIDZ2, 4 wide | 24 TB | 23.25 TB | 23.11 TB | 2 |
| 8 x 16 TB | RAIDZ2, 8 wide | 96 TB | 91 TB | 90.86 TB | 2 |
| 24 x 16 TB | 4 x RAIDZ2, 6 wide | 256 TB | 255.75 TB | 255.61 TB | 2 per vdev |
The 8 x 16 TB RAIDZ2 pool by record size: data written in 16K records fills about 85.33 TB, 128K records about 91.02 TB and 1M records about 95.81 TB, before the slop space. The same pool as a media library (1M records) and as VM storage (16K blocks) differs by about 10.48 TB. A 24 drive pool is past the point where this calculator says dRAID is not modelled.
Widening a 5 x 8 TB RAIDZ2 vdev that holds 12 TB to 6 drives: a new 6-wide vdev would hold 32 TB, the widened one about 30.67 TB, so 1.33 TB is held by the old ratio until that data is rewritten.
Slop space, full pools and the 80% figure
Three different things get called "the limit", and only the first is enforced by ZFS:
- Slop space. OpenZFS holds back 1/32 (about 3.2%) of a pool by default (spa_slop_shift=5); with less free space than that, most writes and file creates fail with an out of space error. The OpenZFS slop reserve is 1/32 of pool space, capped at 128 GiB, and never less than 128 MiB (or half the pool on a pool smaller than 256 MiB). File removal and most administrative actions may still use half the slop space, so a pool that is out of space for writes can still be cleaned up. (OpenZFS, checked 2026-10-07) The headline figure above already takes it off.
- Slower allocation. When a metaslab has less than 4% free, the OpenZFS allocator switches from first fit to a slower best fit search. (OpenZFS, checked 2026-10-07) TrueNAS says that at about 96% full ZFS switches to best fit allocation, which most workloads will notice. (TrueNAS, checked 2026-10-07)
- Your planning threshold. TrueNAS calls 80% full a starting point, not a hard limit: write once archival pools can reasonably run to 90 or 95%, while heavy random I/O pools may need to stay below 80%. (TrueNAS, checked 2026-10-07) The calculator starts at 80% and you can set your own.
RAIDZ1, RAIDZ2 or mirrors?
There is no drive size where RAIDZ1 stops being reasonable. RAIDZ1 survives one failed drive per vdev, so while a resilver runs that vdev has nothing left to lose. These push towards RAIDZ2, RAIDZ3 or 3-way mirrors:
- a long resilver, which grows with drive size, with how full the pool is and with how busy it is while it resilvers;
- a long wait for a replacement drive;
- more drives sharing the risk in one vdev, and drives of the same age;
- no tested backup of the data.
The cost is one more drive of capacity per vdev, which this calculator shows. To put numbers on the window for your own pool, the Drive Failure Risk Estimator takes the resilver time worked out above as its rebuild time. The RAID Rebuild Time and Risk Estimator gives a full-drive rebuild comparison: it rebuilds the whole drive, not only the data on it, so it shows a longer time than a resilver of a part-full ZFS pool.
Mirrors give up more capacity (half the drives in 2-way mirrors) and usually suit random I/O, and a mirror vdev grows by replacing every drive in it with a larger one. Several narrower vdevs survive more failures in total than one wide vdev, but losing any one vdev still loses the pool.
ZFS on Unraid
This calculator applies to Unraid ZFS pools. The traditional Unraid parity array is a different design: for that, use the RAID calculator's Unraid mode and the Unraid Rebuild Estimator.
- From Unraid 7.0 the traditional array is optional: a server can run with only ZFS or Btrfs pools. (Unraid, checked 2026-10-07)
- On Unraid, adding a device to a 2 way or 3 way ZFS mirror pool makes it a 3 way or 4 way mirror. (Unraid, checked 2026-10-07)
- Unraid 7.2 can expand a single vdev RAIDZ1, RAIDZ2 or RAIDZ3 pool one drive at a time. (Unraid, checked 2026-10-07)
- The Unraid ZFS storage guide still says a single disk cannot be added to an existing vdev in the WebGUI; the 7.2.0 release notes say single vdev RAIDZ expansion is now supported. Treat the release notes as the newer statement. (Unraid, checked 2026-10-07)
Sizing a cache pool rather than main storage? Use the Unraid cache calculator.
How we calculate
- Layouts. NTK's curated set of common equal splits, not every possible split: a stripe of single drives, 2-way and 3-way mirrors when the count divides evenly, and RAIDZ1 (3 or more drives per vdev), RAIDZ2 (4 or more) and RAIDZ3 (5 or more) as one vdev, or as 2, 3 or 4 equal vdevs (2 for RAIDZ3). For pools of 2 to 4 drives it also lists RAIDZ at its smallest legal width, one drive more than its parity, such as a 2-drive RAIDZ1. A RAIDZ vdev needs at least one more drive than its parity level: 2 drives for RAIDZ1, 3 for RAIDZ2 and 4 for RAIDZ3. (OpenZFS, checked 2026-10-14) Unraid 7.2 mirrors a two drive ZFS pool by default, and lets you make it RAIDZ1 instead if you plan to expand that vdev later. (Unraid, checked 2026-10-14) A RAIDZ vdev at that smallest width holds no more than a mirror of the same drives, so it is listed but scored below the mirror.
- Nominal capacity per vdev is (drives minus parity) x drive size for RAIDZ, one drive for a mirror, and every drive for a stripe. The pool adds up its vdevs.
- What ZFS reports. For RAIDZ, ZFS works out how many sectors one 128K block takes at your sector size and vdev width, parity and padding included, and counts the whole vdev at that ratio. That is usually a little less than nominal.
- Slop space is 1/32 of the reported space, at least 128 MiB and at most 128 GiB (about 0.14 TB). On any pool reporting more than about 4.4 TB that is the 128 GiB cap, not 3%. The headline is reported space minus slop.
- Your record size uses the same sector rule for blocks of the size you pick: small blocks need proportionally more parity and padding sectors on RAIDZ, large ones less. The range shown runs from 16K to 1M blocks. Mirrors store every block in full on each drive, so it does not change them.
- Plan on storing is your planning threshold x the smaller of two figures: the headline, and what data in your block size can fill once the slop space is taken off. With large blocks the headline is the smaller. With small blocks on RAIDZ (zvols and VMs, for example) the second is smaller, and the plan follows it so you do not plan to store more than the pool can hold.
- Resilver time is the data on the replaced drive (drive size x pool fill) divided by the speed range you pick. Both are inputs, not measurements.
- RAIDZ expansion: the data already stored keeps the old vdev width's ratio of (drives minus parity) / drives, and new space fills at the new width's ratio. The difference from a new vdev of the final width is the TrueNAS calculator's headroom figure.
- The recommendation scores each layout on the workload and priority you pick: mirrors score higher for VM and database storage, RAIDZ for media and backups, more parity for the resilience priority, more space for the capacity priority, and with drives over 4 TB more parity scores higher. A RAIDZ vdev wider than 9 drives scores lower under every priority, so a large pool is recommended as several narrower vdevs; the wide vdev stays in the table of other layouts. OpenZFS recommends between 3 and 9 drives in each RAIDZ vdev, for performance. (OpenZFS, checked 2026-10-14) That weighting is NTK's editorial judgement, so the other layouts are listed with their figures.
Assumptions NTK made
- Mirrors: OpenZFS: a sequential resilver (
zpool replace -s, mirrors and dRAID) reconstructs only allocated capacity. A default resilver scaling with pool fill is an NTK planning assumption. - RAIDZ: scaling with pool fill is an NTK planning assumption.
- Every drive is as full as the pool. NTK planning assumption.
- Resilver speed ranges are NTK planning assumptions, shared with the RAID Rebuild Time and Risk Estimator.
- Records are not compressed, and all drives in the pool are the same size.
- dRAID is not modelled; from 20 drives the calculator says so. QNAP QuTS hero is ZFS based but its own reserves and rules are not modelled. The traditional Unraid array is not ZFS and is not modelled here.
- Workload fit and the recommendation are NTK's guidance, not a vendor rule.
Sources this calculator uses
| Fact | Source | Checked |
|---|---|---|
| How ZFS counts space | ||
| A RAIDZ group of N disks of size X with P parity disks holds approximately (N minus P) x X and survives P failed disks. | OpenZFS | 2026-10-07 |
| OpenZFS reports RAIDZ pool space as if every block were 128K, using the vdev's original width. | OpenZFS | 2026-10-14 |
| OpenZFS allocates a RAIDZ block as its data sectors plus parity sectors per row, rounded up to a multiple of (parity + 1) sectors. | OpenZFS | 2026-10-12 |
| RAIDZ space efficiency depends on block size: OpenZFS's own example 3 disk RAIDZ1 stores 4K records at 50% efficiency and 128K records at about 66%; wider vdevs are more efficient. | OpenZFS | 2026-10-07 |
| The default ZFS recordsize is 128 KiB. | OpenZFS | 2026-10-07 |
| Changing a dataset's recordsize affects only files written afterwards; existing files keep their block size. | OpenZFS | 2026-10-07 |
| Slop space and full pools | ||
| OpenZFS holds back 1/32 (about 3.2%) of a pool by default (spa_slop_shift=5); with less free space than that, most writes and file creates fail with an out of space error. | OpenZFS | 2026-10-07 |
| The OpenZFS slop reserve is 1/32 of pool space, capped at 128 GiB, and never less than 128 MiB (or half the pool on a pool smaller than 256 MiB). | OpenZFS | 2026-10-14 |
| File removal and most administrative actions may still use half the slop space, so a pool that is out of space for writes can still be cleaned up. | OpenZFS | 2026-10-14 |
| When a metaslab has less than 4% free, the OpenZFS allocator switches from first fit to a slower best fit search. | OpenZFS | 2026-10-07 |
| TrueNAS says that at about 96% full ZFS switches to best fit allocation, which most workloads will notice. | TrueNAS (iXsystems) | 2026-10-07 |
| TrueNAS calls 80% full a starting point, not a hard limit: write once archival pools can reasonably run to 90 or 95%, while heavy random I/O pools may need to stay below 80%. | TrueNAS (iXsystems) | 2026-10-07 |
| Growing a pool | ||
| When ZFS drives are replaced with larger ones, the new space appears only after every disk in that mirror or RAIDZ group is larger (autoexpand, off by default). | OpenZFS | 2026-10-07 |
| Attaching a disk to a ZFS mirror adds another copy (two way becomes three way); it adds redundancy, not capacity. | OpenZFS | 2026-10-07 |
| RAIDZ expansion (adding a disk to an existing RAIDZ vdev) is a feature of OpenZFS 2.3.0. | OpenZFS | 2026-10-07 |
| RAIDZ expansion keeps the parity level (a RAIDZ2 stays a RAIDZ2), can be repeated, and the added disk must be at least as large as the smallest disk in the vdev. | OpenZFS | 2026-10-07 |
| After RAIDZ expansion, blocks written before it keep their old data to parity ratio; only new blocks use the wider ratio, and tools may report slightly less space than expected. | OpenZFS | 2026-10-07 |
| An extended RAIDZ vdev can report less capacity than a new vdev of the same width; rewriting old data recovers the real space, but reported capacity keeps the old ratio. | TrueNAS (iXsystems) | 2026-10-07 |
| TrueNAS's calculator estimates headroom lost to a one step extension as drive size x fill fraction x parity disks x (final width minus initial width) / final width. | TrueNAS (iXsystems) | 2026-10-07 |
| Layouts | ||
| A RAIDZ vdev needs at least one more drive than its parity level: 2 drives for RAIDZ1, 3 for RAIDZ2 and 4 for RAIDZ3. | OpenZFS | 2026-10-14 |
| OpenZFS recommends between 3 and 9 drives in each RAIDZ vdev, for performance. | OpenZFS | 2026-10-14 |
| Unraid 7.2 mirrors a two drive ZFS pool by default, and lets you make it RAIDZ1 instead if you plan to expand that vdev later. | Unraid documentation | 2026-10-14 |
| In OpenZFS, a sequential resilver (used for mirrors and dRAID) reconstructs only allocated capacity, so its time follows how full the pool is. | OpenZFS | 2026-10-19 |
| Scope, RAM and drive sizes | ||
| dRAID arrived in OpenZFS 2.1.0 and TrueNAS 23.10; TrueNAS recommends it only for arrays with very many disks (more than 100) storing large blocks. | TrueNAS (iXsystems) | 2026-10-07 |
| TrueNAS asks for at least 8 GB of RAM for basic operation with up to eight drives, plus more for VMs, apps, many clients and especially deduplication. | TrueNAS (iXsystems) | 2026-10-07 |
| Seagate's IronWolf Pro NAS drive range goes up to 32 TB. | Seagate | 2026-10-07 |
| WD Red Pro NAS drives come in capacities from 2 TB to 26 TB. | Western Digital | 2026-10-07 |
| ZFS on Unraid | ||
| From Unraid 7.0 the traditional array is optional: a server can run with only ZFS or Btrfs pools. | Unraid documentation | 2026-10-07 |
| On Unraid, adding a device to a 2 way or 3 way ZFS mirror pool makes it a 3 way or 4 way mirror. | Unraid documentation | 2026-10-07 |
| Unraid 7.2 can expand a single vdev RAIDZ1, RAIDZ2 or RAIDZ3 pool one drive at a time. | Unraid documentation | 2026-10-07 |
| Unraid 7.2 shows an "invalid expansion" warning when a ZFS pool has to be upgraded before it can be expanded. | Unraid documentation | 2026-10-14 |
| The Unraid ZFS storage guide still says a single disk cannot be added to an existing vdev in the WebGUI; the 7.2.0 release notes say single vdev RAIDZ expansion is now supported. Treat the release notes as the newer statement. | Unraid documentation | 2026-10-07 |
OpenZFS, TrueNAS and Unraid statements checked at source: 2026-10-07 to 2026-10-19.
AU NAS drive market prices
NAS and enterprise drives sold by Australian retailers, with the current market price for each. Compare individual retailers on Staticice. Seagate's IronWolf Pro NAS drive range goes up to 32 TB. WD Red Pro NAS drives come in capacities from 2 TB to 26 TB.
| Drive | Capacity | AU market price |
|---|---|---|
| Seagate IronWolf Pro | 8 TB | $689 |
| Seagate IronWolf Pro | 12 TB | $954 |
| Seagate IronWolf Pro | 16 TB | $1265 |
| Seagate IronWolf Pro | 20 TB | $1538 |
| WD Red Pro | 8 TB | $689 |
| WD Red Pro | 12 TB | $999 |
| WD Red Pro | 16 TB | $1269 |
| Seagate Exos | 12 TB | $1010 |
| Seagate Exos | 16 TB | $1349 |
Market prices, last changed 23 October 2026. Each figure is the typical going rate across the Australian retailers we track, checked daily against their listings. A drive stocked by fewer than 3 retailers shows no price. Confirm the price with the retailer before you buy.
Warranty: a drive's warranty term is the manufacturer's own, so check its datasheet. Your first step for a faulty product is usually the retailer that sold it. The ACCC explains your rights under the Australian Consumer Law at accc.gov.au. The vdev runs with less redundancy until a replacement arrives and resilvers, so a spare drive on the shelf shortens that wait.