Quick answer

All three now ship OpenZFS 2.3+, so the storage engine is identical; the choice is really about the interface. Pick TrueNAS for the best ZFS GUI, Proxmox if virtualization is the real job and storage rides along, or Unraid if you have mismatched drive sizes to pool. After that, the pool layout matters more than the badge.

By LK Wood IV · Published 2026-05-07 · Updated 2026-07-05 · ~16 min read · St. Louis County, MO

ZFS vdev topology comparison table for a six-drive 6x16TB homelab pool: 6-wide RAIDZ2 (~1 drive IOPS, 64TB, 2-drive fault tolerance), two 3-wide RAIDZ1 vdevs (~2 drive IOPS, 64TB), and three 2-wide mirror pairs (~3 drive IOPS, 48TB), showing mirrors win on small-block IOPS for VMs while RAIDZ2 wins on media capacity

TL;DR · The 2026 storage call

  • Multi-drive homelab, irreplaceable data: ZFS (OpenZFS 2.3+) on TrueNAS CE 25.10, Proxmox VE 9, or Unraid 7. Battle-tested + bit-rot detection + clean rebuilds.
  • 4-bay default: RAIDZ1 for capacity, striped mirrors for IOPS. Skip RAIDZ2 on 4 drives — capacity loss not justified.
  • SLOG NVMe: Only if sync writes (NFS to VM disks, DB, iSCSI). For SMB / async writes, do nothing.
  • RAM: 16 GB minimum for ZFS, 32 GB is the homelab sweet spot. 1 GB/TB is outdated dedup-era advice.
  • Special vdev: Year-2 project. Mirror-only. Cuts library scan times from minutes to seconds on large media collections.
  • Don't: Run ZFS dedup at home. Run RAIDZ1 with 6+ TB drives without scheduling regular scrubs. Trust a non-ECC system with a 40 TB array — ECC matters more as capacity grows.

Tested against OpenZFS 2.3+ · TrueNAS CE 25.10 Goldeye · Unraid 7.x · Proxmox VE 9.x. All ZFS commands shown apply to all three platforms unless noted.

Which OS to pick — Proxmox VE, TrueNAS Community Edition, or Unraid — is the TL;DR above, and platform UI differences that still matter covers the detail further down. This article is the next decision once you have picked: how to build the storage pool that lives underneath. Filesystem choice, vdev geometry, NVMe SLOG, ARC and L2ARC, and the special vdev that quietly replaces both for most home workloads.

The short version is that storage backend choice has more impact on your real-world IOPS than the OS choice does. A Proxmox host with the wrong vdev layout will lose to a TrueNAS host with the right one, and vice versa. The same OpenZFS 2.3 code now ships in all three platforms, so the differentiation is no longer “which OS has ZFS”; it is “which one lets you build the pool you want without fighting the UI.”

Methodology and sources

This is a research-based storage-backend guide. The filesystem behavior, vdev-geometry tradeoffs, and tuning guidance below are drawn from OpenZFS project documentation, vendor release notes, and third-party benchmark coverage — cited inline at each claim. Where a quantitative relationship is described (for example, that a RAIDZ vdev delivers roughly a single drive’s small-block IOPS), it reflects published OpenZFS behavior rather than a one-off bench run.

Primary sources used in this article:

Last updated: 2026-07-05. Sources reviewed and current as of this date.

What changed in the storage layer for 2026

OpenZFS 2.3 shipped in early 2025 and is now the common floor across all three platforms. The Register’s coverage of the 2.3 release summarizes the three changes that matter most for home labs: RAIDZ expansion (you can finally add a single disk to a RAIDZ vdev without rebuilding), Fast Dedup (table dedup is now usable on commodity RAM budgets), and Direct IO for NVMe pools (read and write paths can bypass the ARC entirely on flash).

The FreeBSD Foundation’s deep-dive on RAIDZ expansion is worth reading if you have ever lost a weekend rebuilding a Z2 pool to add capacity. Expansion preserves the original failure tolerance of the vdev — a Z1 pool stays Z1, a Z2 pool stays Z2 — and the operation runs while the pool is online. It reached homelab users in TrueNAS SCALE 24.10 “Electric Eel” on October 29, 2024 — drive-at-a-time, online, at single, double, or triple parity — after years of development, and it now ships on every current build of all three platforms. This single change kills the strongest historical argument for Unraid’s parity-array model in mid-size labs: you no longer have to choose a mix-any-disk parity array just to keep the option of adding one drive later.

TrueNAS 25.10 “Goldeye” inherits OpenZFS 2.3 and queues OpenZFS 2.4 for the TrueNAS 26 cycle (still in beta as of mid-2026) with hybrid pool improvements and intelligent tiering between NVMe and HDD. Proxmox has since moved past that floor: VE 9.0 shipped OpenZFS 2.3.3 in August 2025, and the current VE 9.2 (May 2026) ships OpenZFS 2.4. Unraid 7.3 ships OpenZFS 2.4.1. The OpenZFS 2.3 baseline this article describes is now met on every platform — and already exceeded on Proxmox and Unraid stable.

The platform-level summary earlier on this page is still accurate, but the storage-layer differences underneath have narrowed. The remaining differences are in the UI, the defaults, and the special-case features each one chooses to expose.

ZFS vs btrfs vs ZFS-on-Unraid: the honest tradeoffs

There are three real filesystems you will choose from in 2026, and they map to different operational philosophies.

FilesystemBest forKey strengthKey weakness
ZFS (RAIDZ, mirrors)Anything that has to survive a drive failure cleanlyAtomic snapshots, send/receive replication, ARC, end-to-end checksummingRequires uniform drive sizes per vdev; rebuild can take days on large drives
btrfs (RAID 1, RAID 10)Mixed-size SSD cache pools, tinker-friendly setupsOnline RAID profile changes, dynamic device add/removeRAID 5/6 still flagged experimental in 2026 (Unraid docs)
ZFS-on-UnraidUnraid users who want ZFS for one or two poolsInherits ZFS data integrity inside Unraid’s cache-pool modelNo spare vdev support as of Unraid 7.1.2 (Unraid ZFS docs); pool drives must be uniform size

The “ZFS requires 1 GB of RAM per 1 TB of storage” rule is dead. Unraid’s own 2026 documentation now explicitly calls that advice outdated. ARC scales to whatever RAM you give it, and the marginal benefit drops off fast above your active working set.

The “btrfs RAID 5/6 is experimental” warning is still alive in 2026 and not resolved. Unraid’s cache pool documentation flags it explicitly; ZFS handles parity RAID more maturely and is the recommended choice for any pool above mirrored pairs.

For a four-drive NVMe cache pool on Unraid that mixes, say, a 1TB drive with three 2TB drives, btrfs RAID 1 is the only option that actually works — ZFS pools on Unraid require uniform drive sizes, which is the same drive-size rule that drives most people to Unraid’s parity array in the first place. For everything else, ZFS is the right answer.

RAIDZ vs mirrors: where IOPS actually live

The single biggest performance lever in a ZFS pool is vdev geometry. RAIDZ vdevs and mirror vdevs are both useful; they are not interchangeable.

Both the Linus Tech Tips ZFS best practices thread and the OpenZFS workload-tuning guide describe the same well-established behavior: a single RAIDZ vdev delivers roughly the small-block random IOPS of a single drive, regardless of how many disks are in it; streaming throughput scales with the data-disk count, but small-block random IOPS does not. Mirror vdevs deliver one drive’s worth of IOPS per mirror pair, and a pool of N mirror pairs delivers approximately N times that.

The practical consequence for a six-drive pool:

TopologySmall-block random IOPSUsable capacity (6×16 TB)Fault tolerance
1× RAIDZ2 (6-wide)~1 drive’s worth64 TB2 drives
2× RAIDZ1 (3-wide)~2 drives’ worth64 TB1 per vdev
3× mirror (2-wide)~3 drives’ worth48 TB1 per vdev (best random IOPS)

The table is the math; here is the same six drives as physical bays, so you can see where the capacity and the IOPS actually go.

Same six drives, three ways
Six 16 TB drives, 96 TB raw, laid out three ways. What changes is how many bays you spend on redundancy and how the random IOPS multiply. Data, Parity, Mirror copy.
1× RAIDZ2, 6-wide · max capacity, media pool
DATA
DATA
DATA
DATA
PAR
PAR
64 TB usable ~1 drive of random IOPS survives any 2 failures
2× RAIDZ1, 3-wide · the balanced middle
DATA
DATA
PAR
DATA
DATA
PAR
64 TB usable ~2 drives of random IOPS 1 failure per vdev
3× mirror, 2-wide · max IOPS, VM/DB pool
DATA
COPY
DATA
COPY
DATA
COPY
48 TB usable ~3 drives of random IOPS 1 failure per pair
Mirrors spend half the raw capacity on copies but roughly triple the random IOPS — exactly what a VM or database pool wants. RAIDZ2 keeps the most usable TB for the least parity, at one drive's worth of random IOPS — exactly what a media pool wants. Same drives; the layout picks the winner.
The colored bays show how much capacity each layout spends on redundancy — not fixed physical roles. Unlike Unraid's dedicated parity disk, RAIDZ stripes its parity across every drive in the vdev (no single drive is "the parity drive"), and ZFS mirror members are equal peers, not a primary and a backup.
techfuelhq.com · 6×16 TB, OpenZFS 2.3+ vdev geometry

Three mirror pairs deliver several times the small-block random IOPS of a single 6-wide RAIDZ2, at the cost of usable capacity. That is the canonical mirror-vs-RAIDZ tradeoff: less parity overhead buys substantial IOPS multipliers on small-block work, which is precisely the pattern of a homelab running VMs and databases. RAIDZ wins on bulk media storage where streaming MB/s is the metric and small-block IOPS does not matter. The NAS & RAID storage calculator works out usable capacity for each of these RAIDZ and mirror layouts so you can see the parity overhead before committing drives.

For a homelab whose pool is mostly hosting iSCSI for Proxmox or NFS for a Kubernetes node, mirrors. For a homelab whose pool is mostly Plex media and infrequent Time Machine backups, RAIDZ2.

NVMe SLOG: when it actually helps

The SLOG (separate log device) is the most misunderstood ZFS feature in homelab forums. It is not a write cache. It does not speed up most writes. It speeds up exactly one thing: synchronous writes that would otherwise commit to the in-pool ZIL.

A practical Reddit thread on enterprise NVMe SLOGs and TrueNAS forum coverage of when SLOG matters both make the same point: SLOG only helps if your workload calls fsync() a lot. NFS writes from VMware or Proxmox, iSCSI for VM storage, and PostgreSQL with synchronous_commit=on are the real winners. SMB writes from a desktop client are async by default and see zero benefit from a SLOG.

The effect is dramatic where it applies: a synchronous 4K random-write workload (--sync=1 --rw=randwrite --bs=4k) against an NFS-mounted dataset can improve by an order of magnitude when a low-latency, power-loss-protected NVMe device such as an Optane drive is configured as SLOG, while the same workload run async (--sync=0) shows no measurable difference because async writes never touch the ZIL. ServeTheHome’s storage coverage and the OpenZFS workload-tuning guide both describe this sync-only behavior.

The drive matters. A SLOG device must have power-loss protection (PLP) and very low write latency. Consumer NVMe drives without PLP can lose data on power loss and frequently land in the same latency band as the spinning pool, which gives you a SLOG that is no faster than the pool it is supposed to accelerate. Enterprise drives like the Intel Optane P1600X (still findable used at $80–$120 in 2026), the Solidigm D7-PS1010, or the Micron 7450 MAX are the right hardware. A 32GB partition is more than enough for a 10GbE pool.

If your homelab pool serves only SMB and async workloads, skip the SLOG entirely. An async-only pool — for example, one backing a desktop SMB share alongside builds like the $1,500 RTX 5060 Ti build and self-hosted local LLM rig — gains nothing from a SLOG, because none of that traffic is synchronous.

ARC and L2ARC: the cache hierarchy in 2026

ARC is ZFS’s adaptive read cache in RAM. L2ARC is the optional SSD-backed second tier. The 2026 tuning guidance has changed materially since 2022.

TrueNAS forum coverage of the ARC change in 24.04+ notes that the old 50% RAM cap on Linux ZFS is gone. ARC now scales the same way it does on FreeBSD and consumes most of free RAM by default. On a 64GB host, ARC typically grows to fill most of free RAM under load, with the rest reserved for the kernel and any VMs the host runs. Once an ARC is warm, hit rates on a read-heavy homelab pool are commonly very high — which is why L2ARC is irrelevant for almost every home use case.

L2ARC was useful when you had 8GB of RAM and a 200GB working set. With 64GB+ of RAM, which is the floor for a 2026 homelab build, L2ARC mostly burns SSD endurance for negligible hit-rate improvement; the OpenZFS workload-tuning guide recommends adding RAM before reaching for L2ARC.

What replaces L2ARC for most modern homelabs is the special vdev. A special vdev stores metadata and small files (configurable threshold) on dedicated flash, separate from the main pool. The performance gain is large because metadata operations dominate ZFS small-block IO; the risk is that the pool becomes unreadable if the special vdev is lost, which means the special vdev must be at least as redundant as the main pool. A mirrored pair of Optane drives configured as the special vdev with special_small_blocks=32K puts every file under 32KB on the flash mirror, delivering metadata operations at NVMe latency on a spinning-disk pool with no L2ARC required.

The reason the cache hierarchy is shaped the way it is comes down to one brutal fact: the tiers are orders of magnitude apart in latency, so where a read lands matters far more than how clever any single tier is.

What actually lives where
The ZFS read path, top (fastest) to bottom (slowest). Bar length is latency on a log scale — each step down is 10–100× slower than the one above.
ARC
RAM
~100 ns
special vdev
NVMe mirror
~10 µs
L2ARC
SATA/NAND SSD
~100 µs
pool
HDD RAIDZ/mirror
~10 ms
nanosecondsmicrosecondsmilliseconds
RAM to a spinning pool is about 100,000×. That chasm is why parking metadata and small files on the special vdev (tier 2) transforms a HDD pool — and why a second SSD cache tier (L2ARC, tier 3) rarely earns its endurance cost once ARC has 32–64 GB of RAM to fill. Add RAM before you add L2ARC.
techfuelhq.com · approximate read latencies, order-of-magnitude

Platform UI differences that still matter

OpenZFS 2.3 normalizes the underlying filesystem; the platforms still expose it differently.

TrueNAS Community Edition 25.10 has the best ZFS pool UI in 2026, full stop. Pool creation, vdev layout, special vdev assignment, SLOG configuration, replication tasks, and snapshot scheduling are all first-class UI features. ARC stats live on the Reporting tab. If you want ZFS without typing zpool or zfs commands, this is the platform.

Proxmox VE 9 treats ZFS as a first-class storage backend but does not expose every feature in the GUI. Pool creation works through the installer or zpool create; SLOG and special vdev assignment require CLI; replication is per-VM through the GUI. This is the right platform if you want full hypervisor control and are comfortable in a shell.

Unraid 7 added native ZFS pools in 7.0 and has refined them through the 7.3 line (7.3.0 shipped May 12, 2026 on OpenZFS 2.4.1; 7.3.1 moved to 2.4.2). The UI handles ZFS pool creation, RAIDZ levels, and basic ZFS dataset operations, and 7.3 finally added a user-facing control for the ZFS ARC-max size plus a “show corrupted files” view in pool status — two things that previously meant editing a config or dropping to a shell. Special vdev support arrived in 7.1; ZFS spare-vdev support is still missing as of 7.3, so there is no hot-spare auto-replace for a ZFS pool the way TrueNAS offers. For Unraid users who want ZFS for a Docker cache pool or an appdata pool, this works well; for a primary VM storage pool, TrueNAS or Proxmox give you more control.

The difference comes down to where you want to spend your time: TrueNAS spends it in the UI, Proxmox spends it in the shell, Unraid spends it switching between modes.

A decision tree for the storage backend

If you are starting a 2026 homelab from scratch:

  1. Mostly VMs, mostly small-block IO, mostly sync workloads (NFS/iSCSI): ZFS, mirror vdevs, mirrored Optane SLOG, mirrored special vdev. TrueNAS or Proxmox host.
  2. Mostly media storage, mostly streaming reads, mostly async (SMB): ZFS, RAIDZ2 vdev, no SLOG, ARC only. Any of the three platforms works.
  3. Mixed drive sizes you cannot replace, willingness to accept worse IOPS: Unraid parity array, btrfs cache pool. Skip ZFS entirely on the array.
  4. Single-purpose backup target, willing to sacrifice IOPS for capacity efficiency: ZFS, single wide RAIDZ2 or RAIDZ3 vdev, no SLOG, no special vdev. Snapshot replication target only.

The fourth case is the one most homelabbers underweight. A backup target does not need IOPS — it needs capacity efficiency, snapshot semantics, and zfs send compatibility with the production pool. A single 8-wide RAIDZ2 with no cache layer is correct here, and it is the same topology that would be wrong for a primary storage pool.

A reference build that gets the tradeoffs right

A strong general-purpose 2026 homelab pool looks like this: three mirror pairs of 16TB drives, a mirrored pair of Optane P5800X for SLOG, and a mirrored pair of Optane P1600X for the special vdev with special_small_blocks=32K. Compression set to zstd-3 on every dataset; deduplication off; ARC left at its default (which fills most of free RAM on a 64GB box). That pool serves iSCSI to a Proxmox cluster, NFS for replication, and SMB to desktops, with a separate wide-RAIDZ2 pool as the nightly zfs send backup target that otherwise stays idle.

The reason this layout works is priority order: getting the vdev geometry right is the largest performance lever, the special vdev is the next, and ARC tuning is mostly a matter of leaving the modern defaults alone (especially on TrueNAS 25.10). None of the platform UI differences matter as much as the topology choice underneath.

If you take one thing from this article: the OS choice matters less than the vdev layout. A wrong layout on the right OS will lose to a right layout on the wrong OS, every time, in a homelab.

Sources

Build the system around it

The TechFuelHQ PC Builder is a free, open-source picker with real socket / RAM / PSU / GPU clearance checks and a CC BY 4.0 parts dataset. Use it to size a host that actually fits the gear in this article.

Frequently asked questions

Should I use ZFS or btrfs in 2026?
ZFS for two or more drives storing irreplaceable data — it’s the storage backend the homelab ecosystem has actually battle-tested. btrfs is fine for single-disk and is gaining ground on Linux thanks to OpenSUSE / Synology default-use, but ZFS-on-Linux 2.3 in TrueNAS CE 25.10 and Unraid 7 remains the more conservative pick for multi-drive arrays.
RAIDZ1 vs RAIDZ2 vs mirrors for a 4-bay homelab?
4-bay homelab default is RAIDZ1 if you tolerate single-drive failure tolerance and want max usable capacity, or two 2-way mirrors striped if you want better IOPS and faster rebuilds. RAIDZ2 on 4 drives loses too much capacity to be worth it — if you need RAIDZ2 redundancy, go to 6 bays.
Do I need an NVMe SLOG device?
Only if you’re running synchronous writes (NFS shares hosting VM disks, databases, or iSCSI for ESXi clients). For SMB to your media library or general file sharing, the writes are asynchronous and a SLOG does nothing. The ‘always add SLOG’ advice from 2019 is outdated.
How much ARC RAM does ZFS really need?
50% of system RAM is the default ARC ceiling. 16 GB total system RAM gives ZFS 8 GB of cache and runs a 4-bay 24–40 TB array fine. 32 GB doubles cache for read-heavy workloads. The ‘ZFS needs 1 GB per TB’ rule is from the dedup era and doesn’t apply unless you actually run dedup (you should not run dedup).
Is a special vdev (metadata) worth adding?
For a media-heavy NAS — yes, after the array is healthy. A mirrored pair of small NVMe drives configured as special-vdev holds metadata and small files, which dramatically speeds up directory listings and the small-file workloads that ARC and L2ARC don’t help. Three caveats: lose the special vdev and you lose the pool, so always mirror; small_blocks tunable matters; this is a 2nd-year-of-homelab project, not a day-one project.
Can I add ZFS on top of Unraid 7?
Yes — Unraid 7 added native ZFS pool support in 2024 with multi-drive fault recovery and LUKS-on-ZFS encryption. The 2026 reality is you can run either Unraid’s classic parity array OR a real ZFS pool on Unraid, depending on whether mixed drive sizes or ZFS data integrity matters more. You cannot reasonably do both at once on the same machine.
Which should I pick: TrueNAS, Proxmox, or Unraid?
Pick TrueNAS Community Edition if you want ZFS with the best GUI and the box’s main job is storage. Pick Proxmox VE if virtualization is the point and the NAS role is secondary; it runs ZFS natively but expects you in a shell. Pick Unraid if you have mismatched drive sizes you cannot replace, since its parity array pools any-size disks that a ZFS vdev cannot. All three ship OpenZFS 2.3+ in 2026, so the vdev layout underneath matters more than the logo.

Evidence ledger

Last updated
Methodology
This homelab guide was written and edited by Lowell K. Wood IV. Specs, prices, commands, and version numbers are drawn from the official vendor, reseller, and project documentation current on the date above, and were verified before publishing. First-person hardware claims appear only where the article shows a verifiable artifact — a photo, receipt, or measurement — or links to the TechFuelHQ Open Bench Datasets. Every fact is human-verified against its cited source before publishing; AI assists with first-draft structure and source-gathering, not with the verdict. Full editorial standard: methodology.
Update log
  • 2026-08-01 — Last reviewed and updated.
Corrections
Spotted an error or stale price? Email hello@techfuelhq.com. Confirmed corrections are added to the update log above.

About the author

Written by Lowell K. Wood IV. Lowell builds and runs TechFuelHQ from St. Louis, Missouri, pairing thirteen-plus years of hands-on homelab, PC, server, and networking experience with cited third-party testing and first-party benchmarks on the gear he still runs. He also works ground EMS as a Nationally Registered Paramedic (NREMT).