📖 Chapter 03 — Drives, VDEVs, Pools

The physical layer. Why six 12TB drives give you ~44TB usable and not 72TB, and why you can't just add a 7th drive later.

Learning Objectives

• Explain what a vdev is, in your own words, without looking
• Calculate the usable space for a RAIDZ2 vdev of any size
• State why you can't add a single drive to an existing vdev
• Decide between RAIDZ1, RAIDZ2, RAIDZ3, and mirrors for a home pool

Introduction

This is the chapter that demystifies ZFS storage math. If you've ever wondered "why does the filesystem say 44TB free when I bought 72TB of drives?" — this is the chapter that answers it. And if you've ever heard someone say "ZFS is different from RAID" and wondered what they meant — this is also that chapter.

By the end, you'll be able to look at anyone's NAS specification and immediately know: how much space is actually usable, how many drives can fail before data is lost, and what the upgrade path looks like five years from now.

The hierarchy, one more time

From Chapter 02, the stack. We're now going to dig into Layers 2, 3, and 4 in detail.

The pool is the abstraction you create datasets inside. The vdevs are the building blocks the pool is made of. The drives are the physical hardware at the bottom.

The reason this layer exists separately from "just use RAID" is that ZFS's vdevs are more powerful than traditional RAID — and the rules are stricter. The next three sections cover each layer in order.

Hard drives

Drives do exactly two things: store bytes, and report when they're about to die (via SMART — Self-Monitoring, Analysis, and Reporting Technology).

For TK: 6 × 12TB hard drives. They sit in the case, connected to the motherboard's SATA ports (or to an HBA — Host Bus Adapter — card, if there aren't enough SATA ports on the motherboard).

That's the entire job of Layer 2. Anything more — any abstraction, any grouping, any redundancy — happens above this layer.

What a drive does NOT do

A drive does not:

• Know about other drives
• Coordinate with the OS to survive failures
• Verify its own data is correct (SMART monitors health, not correctness)
• Tell you when bytes are silently corrupted (this is called bit rot, and ZFS catches it — see Chapter 09)

VDEVs (Virtual Devices)

A vdev is a group of drives that ZFS treats as one logical device. ZFS never sees individual drives — it only sees vdevs.

The most important fact about vdevs: redundancy happens at the vdev level, not the pool level. A vdev with RAIDZ2 redundancy can survive the loss of 2 of its drives. A pool made of multiple vdevs does NOT gain additional redundancy from being a pool — it just has more storage.

RAIDZ2, explained

RAIDZ2 is the vdev type for TK's build. The "Z" comes from ZFS (it was the first to add this variation), and the "2" means: any 2 drives in the vdev can fail without losing data.

For 6 × 12TB drives in a single RAIDZ2 vdev:

That ~44TB is what you'll see in the web UI as the pool's capacity. The 28TB difference between 72TB and 44TB is not "lost" — it's the price of being able to lose any 2 drives and not lose your family's photos.

RAIDZ1 vs RAIDZ2 vs RAIDZ3

Mirrors

A mirror vdev is a different beast: every drive is a complete copy. With 6 drives, you could do 3 mirrors of 2 drives each, giving you ~12TB of usable space (6TB usable per mirror, 3 mirrors).

Mirrors have great read performance (data can be read from any drive in parallel) and the fastest rebuild of any RAID type. They're commonly used in enterprise environments. For a 6-drive home NAS, you give up too much usable space to make them worthwhile. Stick with RAIDZ2.

The rule that matters: you can't add a single drive to a vdev

This is the gotcha that catches every first-time ZFS builder.

You have a 6-drive RAIDZ2 vdev. Next year, you buy a 7th drive and ask: "Can I just add it to the pool?" No.

You cannot add a single drive to an existing RAIDZ vdev to expand it. The parity math doesn't work — the new drive wouldn't have a parity partner. To expand a vdev, you have to:

• Replace all the drives in the vdev with larger ones, one at a time, and let ZFS grow the vdev after the last one. (Works, but takes a long time and is risky if a drive fails during the process.)
• OR add a whole new vdev to the pool. (Works immediately. The new vdev can be a different size. The pool just gets bigger.)

There is one exception: ZFS RAIDZ expansion (added in OpenZFS 2.2) does allow you to add drives to an existing RAIDZ vdev in some cases. As of 2026 it's supported on some platforms but not all, and the TrueNAS team treats it as advanced territory. The conservative, time-tested path is: add a new vdev when you need more space.

The pool

The pool is the layer that ties everything together. It collects one or more vdevs and presents them as a single filesystem. From the dataset's perspective (Layer 5), the pool is just one big bucket of storage. It doesn't care how many vdevs make up that bucket.

One vdev or many?

For TK's build, one pool, one vdev, six drives. This is the simplest setup and the right one for a home NAS.

Why not multiple vdevs? Three reasons:

1. Simplicity. One vdev means one set of decisions to make, one redundancy policy, one upgrade path.
2. No performance benefit at this scale. Multiple vdevs improve IOPS, but a 6-drive home NAS doesn't need the IOPS.
3. Failure isolation is illusory at home scale. Losing one vdev out of two still means losing half the pool. In a home context, that's a catastrophic event either way.

When you do want multiple vdevs:

• When you're adding a fast SSD vdev alongside a slow HDD pool (mixed performance tier)
• When you have 12+ drives and want to balance IOPS across vdevs
• When you need a dedicated mirror for critical data (e.g. VM storage) inside a larger RAIDZ pool

Pool naming

Name the pool something short, lowercase, and meaningful. You'll be typing it a lot. The ZFS community has converged on `tank` for the main pool — short, distinctive, alliterative with TrueNAS. Alternatives: `main`, `storage`, `nas`, `vault`.

You cannot rename a pool after creation without destroying and re-creating it. Pick once, live with it forever.

Special vdev types

Beyond RAIDZ and mirrors, ZFS has three more vdev types you should know about:

• Log (SLOG) — a dedicated vdev for the ZFS Intent Log. Speeds up synchronous writes dramatically. Built from a mirrored SSD pair. Optional. Most home users don't need one.
• Cache (L2ARC) — a read-cache vdev. Speeds up reads of hot data. Optional. Most home users don't need one.
• Dedup — a dedicated vdev for ZFS dedup tables. Speeds up dedup. Only useful if you've enabled dedup, which you almost certainly haven't.

For a home NAS, all three are advanced topics. Don't worry about them in Volume 1. We'll come back to L2ARC and SLOG in Volume 4 (Home Lab) if your workload demands them.

The math, in one place

For TK's 6 × 12TB RAIDZ2 vdev:

Engineering Note

Summary

A vdev is a group of drives ZFS treats as one device. A pool is one or more vdevs presented as a single filesystem. RAIDZ2 is the right vdev type for a 6-drive home NAS with irreplaceable data. Usable space is roughly (N − 2) × drive size for RAIDZ2. You can't add a single drive to an existing vdev, but you can add a new vdev to the pool. Pick your pool layout once and live with it.

Checklist

• ⬜ Without looking, draw the vdev ↔ pool ↔ drives relationship for your own hardware
• ⬜ Calculate the usable space for your actual drive configuration
• ⬜ Decide: will you go with one vdev (the simple path) or multiple vdevs (the future-proof path)?
• ⬜ Name your pool. You'll type it for the next decade.

Looking Ahead

Chapter 04 covers the layer above the pool: datasets. Datasets are where ZFS becomes interesting. They're the smart folders that get their own permissions, their own compression, their own snapshots, their own encryption. Most of what makes a ZFS system feel modern happens at the dataset layer.

Ch 03 · v0.1 · drafted from the original ChatGPT conversation, July 2026