ZFS AnyRaid: Pools From Mixed Drive Sizes, Finally

For over two decades OpenZFS has enforced a strict rule: inside a VDEV, only the smallest drive counts. Build a RAIDZ2 from 4× 12 TB and 2× 18 TB and you had 6 drives of 12 TB usable — the 12 TB of waste on the larger drives was gone. That rule has forced ZFS users in SMB and homelab environments into workarounds for years: separate VDEVs for different drive sizes, or simply the uncomfortable feeling of giving up a lot of capacity.

With AnyRaid in OpenZFS 2.4 — and therefore in TrueNAS 26 “Halfmoon” — that constraint is lifted for the first time. Pools can be built from drives of different sizes, and every drive contributes its full capacity to the pool.

This article explains what AnyRaid is technically, when it fits — and which limitations to know before replacing an old wasteful topology with it.

What the old behaviour looked like

Classic ZFS RAIDZ2 example: 6 drives, mixed 12 TB and 18 TB:

Disk 1: 12 TB ━━━━━━━━━━ (fully used)
Disk 2: 12 TB ━━━━━━━━━━ (fully used)
Disk 3: 18 TB ━━━━━━━━━━░░░░░ (only 12 TB, 6 TB wasted)
Disk 4: 18 TB ━━━━━━━━━━░░░░░ (only 12 TB, 6 TB wasted)
Disk 5: 12 TB ━━━━━━━━━━ (fully used)
Disk 6: 12 TB ━━━━━━━━━━ (fully used)

Waste:          12 TB total (two drives at 6 TB each)
Usable pool:    ~48 TB raw (RAIDZ2: ~48 TB usable after parity on 6×12 TB)

The waste is not trivial — with growing drive generations the problem compounds. With an 8-bay NAS migrating from 4 TB through 8 TB to 16 TB over years, you can end up with a VDEV that has significant “unused” capacity simply because the first 4 TB disks set the ceiling.

What AnyRaid does technically

AnyRaid changes the data layout logic in ZFS so that parity and data no longer have to live in fixed positions across all drives. Instead:

• Data and parity are organised in stripe groups that need not use all drives at the same time
• Larger drives hold more stripe groups than smaller ones
• Parity guarantees (RAIDZ1/Z2/Z3) are preserved per stripe group

Simplified illustration:

AnyRaid with RAIDZ2 on 6 drives (4× 12 TB + 2× 18 TB):

Stripe group A (12 TB layer): uses all 6 drives
Stripe group B (6 TB layer):  uses only drives 3 and 4 (the larger ones)

  Disk 1: 12 TB ━━━━━━━━━━ (Group A)
  Disk 2: 12 TB ━━━━━━━━━━ (Group A)
  Disk 3: 18 TB ━━━━━━━━━━ ━━━━━ (Group A + Group B)
  Disk 4: 18 TB ━━━━━━━━━━ ━━━━━ (Group A + Group B)
  Disk 5: 12 TB ━━━━━━━━━━ (Group A)
  Disk 6: 12 TB ━━━━━━━━━━ (Group A)

The additional 12 TB (2× 6 TB on disks 3 and 4) remain usable in Group B — but with a different parity topology. Group B is effectively a mirror of the two larger drives, because only these two drives contribute capacity in this layer.

Important consequence: parity behaviour is not uniform across stripe groups. On the larger drives there is a layer with only mirror-level protection (not RAIDZ2). If both larger drives fail simultaneously, the Group-B layer is gone. The Group-A layer (RAIDZ2 across all drives) remains protected by Z2 parity.

What this means in practice

Use case 1: homelab with mixed drives

Classic homelab scenario: 8-bay NAS, populated over years from three procurement rounds. 2× 4 TB, 2× 8 TB, 4× 12 TB. Before AnyRaid: with all in one VDEV, usable is only 8× 4 TB = 32 TB raw. With AnyRaid: the full capacity of each drive is used — the pool is significantly larger, with layered parity guarantees.

Use case 2: stepwise migration to larger drives

Classic migration workflow in TrueNAS: replace drives one by one with larger ones, run a resilver each time. Before AnyRaid: the VDEV only grew once all drives were the new size — and the pool had to explicitly have “auto-expand” enabled. With AnyRaid: as soon as the first drive is replaced, part of its additional capacity is available. The migration becomes linear.

Use case 3: resilver with a larger drive

Before AnyRaid: replacing a 12 TB drive with a 16 TB drive — the extra 4 TB stayed unused until all drives were swapped. With AnyRaid: the larger drive contributes part of its capacity to the pool immediately, even while the other drives are still small.

Use case 4: hardware consolidation

Anyone consolidating two old NAS units into a new TrueNAS pool typically has heterogeneous drive inventories. AnyRaid makes it realistic to combine these without waste — instead of sorting by drive-size classes.

Limitations — what AnyRaid does not solve

Honest list:

1. Parity asymmetry across stripe groups As explained above: on larger drives there are layers with different parity topology. If the “larger” drives fail simultaneously, their exclusive layer is more exposed. With only two larger drives and the rest small, the upper layer is effectively a mirror of those two — Z1-level protection, not Z2.

Recommendation: AnyRaid pools should not combine drives in too extreme size ratios. A mix of 12 TB / 14 TB is clean; 4 TB / 24 TB is topologically unfavourable.

2. Performance characteristics Stripe groups with different drive counts have different I/O characteristics. Write workloads landing in the “smaller” layer behave differently from workloads in the “larger” layer. For most SMB workloads (files, backups, mixed VM load) this is irrelevant; for latency-critical database workloads stick with homogeneous pool topologies.

3. Online topology change between RAIDZ levels remains open AnyRaid addresses drive-size heterogeneity. It does not solve the desire to switch online from RAIDZ1 to RAIDZ2 or to fundamentally change VDEV topology after creation. That feature is still not on the visible roadmap.

4. Pool must be created or upgraded with OpenZFS 2.4 AnyRaid requires OpenZFS 2.4 (see our OpenZFS 2.4 article). A classic ZFS pool created with 2.2 or 2.3 cannot be “half AnyRaid” — either the feature is activated or it is not. After activation no rollback to older ZFS versions.

5. Recommendation still stands: same drive models for production Despite AnyRaid: in production environments we still recommend identical drive models from the same batch. Vibration, firmware behaviour and failure rate statistics are more predictable in homogeneous pools. AnyRaid is a tool, not an invitation to mix.

When AnyRaid makes sense

Scenario	AnyRaid fits
Homelab, organically grown drive inventory	Yes — immediately noticeable capacity gain
SMB NAS, stepwise drive renewal	Yes — migration becomes easier
Resilver with a larger drive	Yes — no waiting for full replacement
Backup pool from donated or shelf-pulled drives	Yes — pragmatic capacity gain
Production database VMs with strict latency requirements	Probably not — homogeneous pools remain safer
Compliance workload with documented drive batch	Probably not — audit trail cleaner with homogeneous

Practical example: migrating an old pool to AnyRaid

Step by step for a typical SMB NAS pool:

1. Check pool health: zpool status -v, no open resilvers or CKSUM errors
2. Verified full backup in place (see 3-2-1 backup)
3. Update TrueNAS to 26 (or higher) — once Halfmoon enterprise is available
4. Pool imports automatically, feature flags not yet activated
5. Conscious decision: activate AnyRaid feature flag via zpool upgrade <pool> — after this step the pool can no longer be imported on older ZFS versions
6. Insert new, larger drives into hot-swap-capable slots
7. Start resilver job: with AnyRaid the additional capacity is automatically taken into the pool
8. Wait for scrub after resilver, confirm pool consistency

Important: even with AnyRaid, multi-day resilvers on large HDDs are still reality. If shorter resilver times are needed, consider dRAID in parallel — that is a different topology decision though.

Interaction with other ZFS features

AnyRaid combines with:

• RAIDZ expansion: extending the VDEV with additional drives still works — even with a different size for the new drive
• Special VDEV (metadata cache on SSD): remains orthogonal — special VDEV setup is independent of data VDEV heterogeneity
• Snapshots and replication: fully compatible — sender and receiver must understand the AnyRaid feature flag, requiring 2.4
• BRT (Block Reference Table): fast clones work in AnyRaid pools too — see the OpenZFS 2.4 article

DATAZONE recommendation

AnyRaid is one of the most understated and practically useful ZFS additions of recent years. For our customers we see three clear use cases:

• Stepwise hardware modernisation: drive renewal becomes linear and economical. Especially SMBs that cannot replace all 24+ drives at once benefit.
• Homelabs and test pools: organically grown drive inventories finally consolidate sensibly
• Backup and archive pools: where performance homogeneity matters less, AnyRaid is an easy capacity gain

But not everywhere: production database pools, mission-critical storage and setups with hard SLA requirements we still build homogeneously. AnyRaid makes heterogeneous pools possible — it does not make them the first choice for every topology.

For a concrete pool design discussion — new build, migration, hardware refresh — reach us via contact. We advise vendor-neutrally, even when the right answer is “do nothing”.

Sources and related articles

• OpenZFS release notes on GitHub — official source for the AnyRaid specification
• OpenZFS wiki — AnyRaid design document (status 2026, see ZFS documentation)
• Our OpenZFS 2.4 user update — context of the 2.4 features
• TrueNAS 26 Halfmoon beta — carrier platform
• ZFS RAID levels explained — basics of ZFS topologies
• ZFS compression — additional capacity lever
• TrueNAS hybrid storage with SSD and HDD — combined with special VDEV
• 3-2-1 backup rule — prerequisite for any pool change