Independent Australian Storage & Infrastructure Authority
Using Unraid? This wizard applies to Unraid ZFS pools, not the traditional parity array. From Unraid 7.0 the traditional array is optional: a server can run with only ZFS or Btrfs pools. Unraid 7.2 can expand a single vdev RAIDZ1, RAIDZ2 or RAIDZ3 pool one drive at a time. ZFS on Unraid

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.

A dataset's recordsize, or a zvol's volblocksize. It changes RAIDZ capacity, not mirrors.
Match the drives' physical sector size. It is set when a vdev is created.
Your estimate. Resilver time and the expansion figures use it.
Starts at 80%, the TrueNAS starting point. Your choice, not a ZFS limit.
No redundancyA pool of single drives has no redundancy. ZFS still checksums the data, but if a drive fails the pool is lost.
dRAID is outside this calculator
No mirror layout for this drive count
RAIDZ1: one failure per vdev
RAIDZ for a random I/O workloadMirrors usually suit VM, container and database storage better than RAIDZ. With more drives, or SSDs in a separate mirror pool, a mirror layout becomes possible.
Calculating
Recommended
ZFS will report (after slop space)
Calculating
Nominal capacity
Geometry: data drives x drive size, before slop
Your record size
Plan on storing
Vdevs x drives
x
Failures tolerated
Resilver time

What record size does to this layout

Other layouts for these drives

LayoutZFS reports (after slop)NominalFailuresResilverSuits

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)

Added one at a time, each at least as large as the smallest drive. The pool fill above is the data already stored, and the figures assume no new data is written between one added drive and the next.

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.

DrivesLayoutNominalZFS reportsAfter slopFailures
4 x 12 TB2 x 2-way mirror24 TB24 TB23.86 TB1 per mirror
4 x 12 TBRAIDZ1, 4 wide36 TB34.88 TB34.74 TB1
4 x 12 TBRAIDZ2, 4 wide24 TB23.25 TB23.11 TB2
8 x 16 TBRAIDZ2, 8 wide96 TB91 TB90.86 TB2
24 x 16 TB4 x RAIDZ2, 6 wide256 TB255.75 TB255.61 TB2 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:

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:

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.

Sizing a cache pool rather than main storage? Use the Unraid cache calculator.

How we calculate

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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

Sources this calculator uses

FactSourceChecked
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.OpenZFS2026-10-07
OpenZFS reports RAIDZ pool space as if every block were 128K, using the vdev's original width.OpenZFS2026-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.OpenZFS2026-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.OpenZFS2026-10-07
The default ZFS recordsize is 128 KiB.OpenZFS2026-10-07
Changing a dataset's recordsize affects only files written afterwards; existing files keep their block size.OpenZFS2026-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.OpenZFS2026-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).OpenZFS2026-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.OpenZFS2026-10-14
When a metaslab has less than 4% free, the OpenZFS allocator switches from first fit to a slower best fit search.OpenZFS2026-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).OpenZFS2026-10-07
Attaching a disk to a ZFS mirror adds another copy (two way becomes three way); it adds redundancy, not capacity.OpenZFS2026-10-07
RAIDZ expansion (adding a disk to an existing RAIDZ vdev) is a feature of OpenZFS 2.3.0.OpenZFS2026-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.OpenZFS2026-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.OpenZFS2026-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.OpenZFS2026-10-14
OpenZFS recommends between 3 and 9 drives in each RAIDZ vdev, for performance.OpenZFS2026-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 documentation2026-10-14
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.Seagate2026-10-07
WD Red Pro NAS drives come in capacities from 2 TB to 26 TB.Western Digital2026-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 documentation2026-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 documentation2026-10-07
Unraid 7.2 can expand a single vdev RAIDZ1, RAIDZ2 or RAIDZ3 pool one drive at a time.Unraid documentation2026-10-07
Unraid 7.2 shows an "invalid expansion" warning when a ZFS pool has to be upgraded before it can be expanded.Unraid documentation2026-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 documentation2026-10-07

OpenZFS, TrueNAS and Unraid statements checked at source: 2026-10-07 to 2026-10-14.

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.

DriveCapacityAU market price
Seagate IronWolf Pro8 TB$689
Seagate IronWolf Pro12 TB$949
Seagate IronWolf Pro16 TB$1265
Seagate IronWolf Pro20 TB$1538
WD Red Pro8 TB$690
WD Red Pro12 TB$1011
WD Red Pro16 TBCheck retailers
Seagate Exos12 TB$999
Seagate Exos16 TB$1339

Market prices, last changed 15 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.

Frequently Asked Questions

What is a vdev?
A vdev is a group of drives that ZFS treats as one unit: a mirror, a RAIDZ group or a single drive. A pool spreads its data across all of its vdevs, so if any one vdev fails the whole pool is lost. Choosing the vdev layout is the biggest decision in a ZFS pool design, because it sets capacity, how many failures each vdev survives and how the pool grows later.
Why does TrueNAS show less space than my drives add up to?
Three things come off before you store anything: parity or mirror copies, the way ZFS counts RAIDZ space, and the slop space ZFS holds back. 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 reports RAIDZ pool space as if every block were 128K, using the vdev's original width. 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). For 8 x 16 TB in one RAIDZ2 vdev that is 96 TB nominal, 91 TB as ZFS reports it and about 90.86 TB after the slop space, in decimal TB. The headline figure on this calculator is that last number.
How much space does ZFS slop take?
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). Because of the cap, any pool reporting more than about 4.4 TB holds back the same 128 GiB (about 0.14 TB), so on a large pool the slop is far below 3.2%. A flat 3% deduction overstates it. 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.
How full can a ZFS pool get?
There are three different limits, and only the first is a hard one. 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. When a metaslab has less than 4% free, the OpenZFS allocator switches from first fit to a slower best fit search. TrueNAS says that at about 96% full ZFS switches to best fit allocation, which most workloads will notice. 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%. This calculator plans to a fill threshold you choose. It starts at 80% and you can change it for your workload.
Does record size change how much I can store on RAIDZ?
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. The default ZFS recordsize is 128 KiB. For 8 x 16 TB in RAIDZ2 at 4 KiB sectors, data written in 16K records fills about 85.33 TB and data in 1M records about 95.81 TB, against the 91 TB ZFS reports. A zvol (block storage for virtual machines) uses its volblocksize instead of recordsize; enter that size in the calculator to see its effect. Changing a dataset's recordsize affects only files written afterwards; existing files keep their block size.
Can I add a drive to an existing RAIDZ vdev?
RAIDZ expansion (adding a disk to an existing RAIDZ vdev) is a feature of OpenZFS 2.3.0. 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. 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. 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. Example: a 5 x 8 TB RAIDZ2 vdev holding 12 TB, widened to 6 drives, can hold about 30.67 TB, where a new 6-wide vdev would hold 32 TB; the 1.33 TB difference comes back only when the old data is rewritten. Unraid 7.2 can expand a single vdev RAIDZ1, RAIDZ2 or RAIDZ3 pool one drive at a time. Check that your platform and its ZFS version offer it before you plan on it.
How else can a ZFS pool grow?
Attaching a disk to a ZFS mirror adds another copy (two way becomes three way); it adds redundancy, not capacity. 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). Adding a whole new vdev adds its capacity to the pool straight away.
Can I mix vdev types in one pool?
It can be done, but NTK advises against it for data vdevs. A pool of mirror and RAIDZ vdevs mixes different performance and different failure tolerance, and losing any one vdev still loses the whole pool. Keep data vdevs the same type and width; this calculator only designs pools that way.
Should I use RAIDZ1 or RAIDZ2?
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 no redundancy left. What matters is how long the resilver runs, which this calculator estimates from your drive size, pool fill and speed range, how long a replacement would take to arrive, how many drives share the risk and whether you have a tested backup. RAIDZ2 costs one more drive of capacity per vdev. The RAID Rebuild Time and Risk Estimator and the Drive Failure Risk Estimator put numbers on that window.
How long does a ZFS resilver take?
This calculator assumes a resilver rewrites the data stored on the replaced drive, so the time scales with how full the pool is: an NTK planning assumption, not a measured figure. At the typical home NAS speed range (50 to 100 MB/s, also an assumption) a 16 TB drive in a pool that is half full takes about 22.2 to 44.4 hours. On a busy pool pick the slower speed range.
Does this calculator cover dRAID or QNAP QuTS hero?
No. It designs mirror and RAIDZ pools for small to medium systems, up to 24 drives, and from 20 drives it says that dRAID is not modelled rather than leaving it out silently. 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. QNAP's QuTS hero is also ZFS based, but its own reserves and rules are not modelled here.
Does this apply to ZFS pools on Unraid?
Yes, for Unraid ZFS pools. The traditional Unraid parity array is a different design and is not modelled here. From Unraid 7.0 the traditional array is optional: a server can run with only ZFS or Btrfs pools. 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 7.2 can expand a single vdev RAIDZ1, RAIDZ2 or RAIDZ3 pool one drive at a time. 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.
How much RAM does a ZFS NAS need?
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. This calculator does not size memory.
How do NAS drive warranty claims work in Australia?
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. A replacement takes time to arrive and the vdev runs with less redundancy until the resilver finishes, so a spare drive on the shelf shortens that wait.
Can I share my design?
Yes. Copy permalink puts every setting in the link, Copy for forum gives a plain-text summary and Cite this result gives a dated citation.

Related tools

RAID Usable Capacity Calculator RAID Rebuild Time and Risk Estimator Drive Failure Risk Estimator Unraid cache calculator