Planning a ZFS Pool: Sizing Guide with Calculator and Three Example Configs

A ZFS pool is not a box full of drives, it is an architecture decision. Anyone who clicks a pool together first and then discovers that the latency is not good enough for the database, or that usable capacity ends up 30 percent below expectations, made the mistake before the first zpool create. This article shows how to plan a ZFS pool properly: which vdev layouts exist, how to calculate RAID-Z capacity, when SLOG, L2ARC or a special vdev actually help, and what three typical setups for a file server, VM storage and a cold archive look like in practice.

ZFS pool planning: the three levers before you pick hardware

Before you think about disk models or chassis, three questions must be answered:

1. How much usable capacity do you need today — and in three years?
2. What is the workload profile: sequential reads, many small writes, mixed VM load, pure archive?
3. What failure tolerance per vdev do you need: one drive, two, three?

Those three answers determine the vdev layout, and only then the concrete count and size of drives. Anyone who reverses the order and starts with hardware usually has to bolt something on later — either cache devices or drives.

A ZFS pool always consists of one or more vdevs that combine into a single pool. Redundancy lives inside a vdev, scaling lives between vdevs. If a vdev loses its redundancy, the entire pool is gone — not just the vdev. That rule is the most important guardrail in every ZFS pool planning session.

vdev layouts to calculate RAID-Z capacity and estimate performance

ZFS knows four redundancy layouts for data vdevs: mirror, RAID-Z1, RAID-Z2 and RAID-Z3. They differ in the number of parity or copy drives per vdev — and therefore in capacity, IOPS and rebuild time.

Mirror vdevs

A mirror vdev holds two or three identical copies of every block. Usable capacity: 50 percent (2-way) or 33 percent (3-way). Upside: highest IOPS per TB and the fastest resilver, because only the data of one drive has to be copied. Downside: more expensive per usable terabyte. For VM storage, databases and anything with many small writes, mirror is almost always the right pick.

RAID-Z1, Z2 and Z3

RAID-Z vdevs distribute data and parity across several drives. Rough rule of thumb for usable capacity:

• RAID-Z1: (n - 1) * drive size, one drive may fail
• RAID-Z2: (n - 2) * drive size, two drives may fail
• RAID-Z3: (n - 3) * drive size, three drives may fail

That formula is an upper bound. In practice usable capacity ends up 5 to 15 percent below the raw number — padding, metadata and ZFS’s own reservation eat the rest. If a datasheet says 100 TB usable, budget 110 to 115 TB gross before you commit.

More important than the exact percentage is the number of drives per vdev. RAID-Z2 with 6 to 10 drives is the sweet spot for classic storage workloads. RAID-Z2 with 16 or more drives looks attractive on paper, but rebuild time climbs to several days once you use 20 TB HDDs — and no other drive in the same vdev may fail during that window. RAID-Z3 is the answer when rebuild time forces a second or third redundancy level.

IOPS rule: A RAID-Z vdev delivers roughly the IOPS of a single drive — regardless of drive count. A pool made of four RAID-Z2 vdevs therefore delivers four times the IOPS of a single vdev. If you want performance, build more vdevs — not wider ones.

The ZFS calculator: from raw capacity to usable pool

A pragmatic calculation path in four steps — the foundation of any ZFS calculator:

1. Set target usable capacity, e.g. 100 TB.
2. Add reserve for snapshots and ZFS overhead: at least 20 percent, better 25 to 30 percent. A pool should never run beyond 80 to 85 percent utilisation — write performance falls off a cliff above that line.
3. Pick the vdev layout and redundancy. Example: RAID-Z2 with 8 drives -> factor 6/8 = 75 percent usable per vdev, minus roughly 10 percent ZFS overhead.
4. Derive vdev count from the IOPS budget and compute the drive size.

Worked example for 100 TB usable, reserved up to 125 TB, RAID-Z2 8-wide: 125 TB / 0.75 / 0.9 = ca. 185 TB raw. Split across two RAID-Z2 vdevs with 8 drives each, that means 16 drives around 12 TB — in practice 16 x 14 TB for a bit of headroom and a clean order.

If you would rather not work the math by hand, our TrueNAS configurator lets you play the same numbers against real models — drive counts and vdev layouts are mapped to the available chassis sizes so you do not have to memorise every datasheet.

Example 1: file server with 100 TB usable

Workload: classic SMB file server, mixed office documents, daily snapshots, monthly offsite replication.

• Layout: 2 x RAID-Z2 with 8 x 14 TB HDDs each (enterprise SAS or SATA, CMR)
• Raw capacity: 224 TB, usable around 110 TB after ZFS overhead
• Redundancy: two drives per vdev
• Cache: no SLOG needed — SMB is mostly asynchronous. A special vdev as a 3-way mirror of small NVMe SSDs (e.g. 1 TB) speeds up metadata and makes ls on large directories feel visibly smoother.
• ARC: 128 GB RAM is a solid starting point at this capacity.

Background on how special vdev and ARC tuning play together is covered in our post on SLOG and special VDEV.

Example 2: VM storage with 50 TB for Proxmox

Workload: 30 to 60 VMs on a Proxmox cluster, mixed Windows Server, Linux and databases. iSCSI or NFS to the hypervisors.

• Layout: 6 x mirror vdev with 2 x 15 TB enterprise NVMe each — or as a cheaper variant 6 x mirror with 2 x 8 TB SATA SSDs
• Raw capacity: 90 TB, usable around 45 TB (50 percent) minus ZFS overhead
• Redundancy: one drive per mirror vdev
• IOPS: deliberately high thanks to 6 vdevs — mirror pools scale per vdev
• SLOG: a dedicated SLOG on two small enterprise NVMe drives (e.g. 200 GB with power-loss protection) as a mirror — mandatory for NFS VM storage with sync=always.
• ARC: 256 GB RAM, no L2ARC required as long as the working set fits in RAM.

Why mirror and not RAID-Z for VMs? Because VM workloads generate many small, scattered writes. RAID-Z forces a full-stripe write for every block — mirror vdevs serve the same IOPS demand with visibly lower latency. If you are still unsure whether VM storage should live on ZFS or Ceph, the decision matrix is in Ceph vs ZFS.

Example 3: cold archive with 300 TB raw

Workload: WORM-style long-term archive, few large reads, mostly sequential writes during ingest, replication target for a second TrueNAS system.

• Layout: 2 x RAID-Z3 with 12 x 20 TB HDDs each (helium, CMR, enterprise grade)
• Raw capacity: 480 TB, usable around 300 TB after RAID-Z3 overhead and ZFS reserve
• Redundancy: three drives per vdev — necessary because a rebuild of a 20 TB drive inside a 12-wide vdev can take 3 to 5 days depending on load
• Cache: no SLOG, no L2ARC — neither pays off for a pure archive
• Compression: zstd-3 as default — overhead is minimal, the benefit on mixed documents is very real
• ARC: 64 GB RAM is enough for this workload

If you want to size a cold archive conservatively, our article on the 3-2-1 backup rule gives the context for how much redundancy to place between primary storage, nearline archive and offsite copy.

SLOG, L2ARC and special vdev: when each add-on actually pays off

These three additional vdevs get confused a lot — although they solve very different problems.

• SLOG (Separate Intent Log): speeds up synchronous writes. Useful for NFS VM storage, databases with O_SYNC, iSCSI with sync=always. Not a general-purpose write cache. Always as a mirror of two small NVMe SSDs with power-loss protection. Without PLP, a power outage can destroy exactly the transactions the SLOG is meant to protect.
• L2ARC: extends the read cache onto fast SSDs. It needs RAM itself for its index structures — an oversized L2ARC eats ARC RAM and slows the pool down. Only worthwhile from around 128 GB RAM and once the working set demonstrably no longer fits in ARC.
• Special vdev: stores metadata and optionally small blocks on a dedicated mirror vdev. Effect: ls on large directories becomes noticeably faster, backup scans finish sooner. Always as a mirror — a single-drive special vdev can destroy the whole pool. Recommendation: 3-way mirror on production systems.

Details on picking the right NVMe for SLOG and special vdev, including sizing rules of thumb, are in our post OpenZFS 2.4 user update.

From planning to configuration

Once the layout is set, the hardware question is the easier part. Chassis, backplane, HBA, CPU cores and network scale linearly with the chosen design. For standard cases we map that directly in the TrueNAS configurator — for special sizes, HA systems or add-ons like 100 GbE or multiple special vdevs, a short sizing session with our IT consulting team usually delivers more value than another datasheet. Prices for the larger systems are quoted as a range or on request — the hardware market moves too much to print flat numbers.

Frequently asked questions on ZFS pool planning

How much capacity do I really lose with RAID-Z2?

On paper (n - 2) / n, e.g. 75 percent for an 8-drive vdev. In reality, after ZFS overhead and the recommended reserve to 80 percent utilisation, roughly 60 to 65 percent of raw capacity remain as usable storage. Plan with that number — not with the raw parity formula.

How big should a SLOG be?

A SLOG only has to buffer about 10 seconds of synchronous writes. At 10 GbE, 16 to 32 GB are enough — the remaining NVMe capacity stays idle. What matters more than size is low latency and power-loss protection.

How many drives per RAID-Z vdev make sense?

RAID-Z1: 3 to 5. RAID-Z2: 6 to 10. RAID-Z3: 10 to 15. Wider vdevs look attractive on paper, but rebuild time and the risk during the rebuild go up sharply.

Can I extend a ZFS pool later?

Yes, with limits. You can add a new vdev — the pool grows, but existing data stays on the old vdevs. Since OpenZFS 2.3 there is also RAID-Z expansion: you can add a drive to an existing RAID-Z vdev. The rebuild is heavy and old blocks keep their old parity ratio — for a real green-field plan it is much better to pick the target layout correctly from the start.

Do I really need ECC RAM for ZFS?

For production systems: yes. ZFS detects and repairs bit-rot on drives, but not in RAM. A faulty RAM module can write checksum-correct but content-wrong data into the pool — a problem for every filesystem, but especially unpleasant on ZFS because the snapshot history carries the bad data forward.

What is the most common planning mistake?

RAID-Z vdevs that are too wide, or too few vdevs. A single 20-drive RAID-Z2 looks attractive on paper but delivers the IOPS of one drive — and produces rebuild times that erode the redundancy. Two 10-drive vdevs instead of one 20-drive vdev are almost always the better choice.