What Is ZFS in Proxmox VE? A Beginner's Guide to Its Built-In Storage System

If you've spent any time in the Proxmox VE installer, you've seen it: right there next to ext4, there's an option called ZFS, with a dropdown full of terms like RAIDZ1, RAIDZ2, and "ashift." Most people click past it, pick ext4 because it looks familiar, and move on. That's a shame, because ZFS is arguably the single biggest reason people end up loving Proxmox once they've used it for a while.

This isn't a tutorial on building a ZFS pool — we've already covered that step by step elsewhere. This is the article for the question that usually comes first: what actually is this thing, and why does Proxmox care about it so much?

What You Will Learn

By the time you're done reading, you'll understand what ZFS is doing under the hood, why Proxmox treats it as a first-class citizen instead of a bolted-on option, and where it genuinely helps versus where it's overkill. A few things we'll cover:

• What ZFS actually is — filesystem, volume manager, and RAID controller rolled into one
• The core features that make it different: checksums, snapshots, compression, and copy-on-write
• The different pool layouts (mirror, RAIDZ1/2/3) and what they trade off against each other
• What ARC is, why it eats RAM, and why that's usually fine
• How to look at a ZFS pool that's already running on your system, using the actual commands
• The errors and gotchas that catch people off guard

What Is This Feature?

ZFS started life at Sun Microsystems in the mid-2000s, and it was designed to solve a problem that traditional RAID and filesystems never handled well: silent data corruption. A regular RAID array can tell you a disk has failed. It can't tell you that a single bit flipped somewhere on a disk that's technically still "healthy." ZFS can, because it checksums every block it writes and verifies that checksum every time it reads the block back.

Technically, ZFS is three things stacked into one system: a filesystem, a volume manager (the part that normally would be RAID or LVM), and a way of pooling storage devices together. In Proxmox, when you pick ZFS during install, you're telling the installer to build something called a pool out of your disks, and that pool becomes the place VM disks, container volumes, ISOs, and backups live.

A pool is built from one or more vdevs (virtual devices). A vdev might be a single disk, a mirror of two disks, or a group of disks in a RAIDZ layout. This is the part that confuses people coming from hardware RAID: you're not choosing "RAID 1" or "RAID 5" for the whole pool — you're choosing a vdev layout, and a pool can technically contain more than one vdev, striped together for extra capacity and speed.

A few features come bundled in whether you think about them or not:

• Checksumming and self-healing — every block gets a checksum, and if your pool has redundancy (a mirror or RAIDZ), ZFS repairs corrupted blocks automatically the next time they're read.
• Copy-on-write — ZFS never overwrites data in place. It writes new blocks and updates pointers, which is part of why snapshots are nearly instant and don't slow the pool down while they exist.
• Snapshots — a point-in-time, read-only copy of a dataset that takes seconds to create and barely any space until the data underneath it starts changing.
• Compression — Proxmox enables lz4 compression by default on ZFS datasets. It's fast enough that it usually speeds things up rather than slowing them down, since there's less data to actually write to disk.

Why Would You Use It?

Honestly, the checksums alone are worth it. Disks fail in boring, predictable ways most of the time — SMART warnings, a drive that just disappears. But every so often a drive returns bad data without throwing any error at all, and that's the failure mode ext4 and hardware RAID are mostly blind to. ZFS catches it.

Then there's snapshots. If you're testing a risky config change, updating a package that might break something, or just experimenting in a homelab, being able to snapshot a VM before you touch it and roll back in a few seconds if it goes wrong changes how comfortable you are taking risks at all.

ZFS also gives you software RAID without a hardware RAID card. That matters more than it sounds — hardware RAID cards hide your disks behind their own controller, which means ZFS can't see individual drives or do its self-healing tricks. If you're building a Proxmox box and it has a RAID controller, the advice you'll hear over and over is to flash it into "HBA mode" (so it passes disks through directly) or avoid it entirely and use the motherboard's SATA ports instead.

Where I'd steer you away from it: a single-disk homelab box with 4 GB of RAM, or a VM where you just need a scratch disk for temporary files. ZFS wants RAM for its cache (more on that below), and its self-healing features need at least two disks to actually do anything. On a single disk, you still get checksums and snapshots, but you lose the "repair corrupted data automatically" part, since there's no second copy to repair from.

Prerequisites

You don't need anything installed — ZFS support ships built into Proxmox VE. What you do need:

• A Proxmox VE host, 8.x or 9.x — the ZFS integration hasn't changed in any way that matters between those releases
• Either a system that was installed with ZFS as the root filesystem, or at least one spare disk you could build a pool from later
• Shell access to the host (the Shell button in the web UI works fine, so does SSH)
• Root or an account with permission to run zpool and zfs commands

If you haven't built a pool yet and want to follow along with the commands below, you can still read through them against a pool you build later — nothing here requires you to create anything new.

Step-by-Step Tutorial

Since this is about understanding what's already there rather than building something new, let's walk through actually looking at a ZFS pool instead of creating one.

Step 1: Check whether you're already running on ZFS. A lot of people install Proxmox with ZFS as the root filesystem without fully registering that they did. In the web UI, go to Datacenter → Storage. If you see an entry with type zfspool, you're running ZFS somewhere on that host already.

Step 2: Look at the pool itself. Open a shell and run:

zpool status

This shows every pool on the system, its layout (mirror, raidz1, and so on), and the health of each disk in it. A healthy pool says state: ONLINE with no errors listed under READ, WRITE, or CKSUM for any disk.

Step 3: Check capacity.

zpool list

This gives you a one-line summary per pool: total size, how much is allocated, how much is free, and a fragmentation percentage. If you're above roughly 80% full, keep that in mind for the Best Practices section below — ZFS gets noticeably slower as a pool fills up.

Step 4: Look at the datasets.

zfs list

Where zpool commands deal with physical disks and redundancy, zfs commands deal with the filesystems (datasets) living inside the pool. This lists every dataset, how much space it's using, and where it's mounted.

Step 5: Check your compression ratio.

zfs get compressratio rpool

(Swap rpool for whatever your pool is actually named — rpool is just the default Proxmox gives the boot pool.) It's genuinely satisfying the first time you see a compressratio of 1.4x or higher on a dataset full of VM disks and realize you're getting extra usable space for free.

Step 6: Peek at ARC usage.

cat /proc/spl/kstat/zfs/arcstats | grep -E "^size|^c_max"

This shows how much RAM ZFS's cache is actually using (size) against its configured ceiling (c_max). If you've ever wondered why a Proxmox box with ZFS seems to be using far more RAM than your VMs and containers add up to, this is usually the answer, and it's expected behavior, not a leak.

Commands Explained

Common Errors

A few messages that tend to send people searching:

state: DEGRADED in zpool status output — one disk in a mirror or RAIDZ vdev has failed or dropped offline. The pool is still working (that's the entire point of redundancy), but you're one more failure away from data loss, so don't leave this sitting for weeks.

insufficient replicas — you've lost enough disks in a vdev that ZFS can no longer guarantee data integrity for that vdev. On a mirror this means both disks are gone; on RAIDZ1 it means two disks are gone.

"Pool uses more space than expected" — this almost always traces back to snapshots. Deleting a file inside a VM doesn't free the space if an old snapshot still references it. Run zfs list -t snapshot to see what's actually holding space.

cannot import 'rpool': no such pool available after a disk swap — usually means the replacement disk wasn't partitioned and attached to the pool correctly, or you're booting with disks in a different order than ZFS expects. This one's more about the replace procedure than ZFS itself being broken.

Troubleshooting

If zpool status shows a degraded pool, start with zpool status -v for the extra detail — it names the exact disk that's causing trouble. From there it's usually a physical disk swap: pull the bad disk, insert a replacement, and run zpool replace <pool> <old-disk> <new-disk>, using the by-id device paths for both.

If the host feels sluggish and you suspect ARC is the cause, check arcstats as shown above. On fresh Proxmox VE 8.1 and later installs, ARC defaults to 10% of installed RAM, capped at 16 GiB — a big change from the historical ZFS default of 50%, which used to catch people off guard on boxes with 8 or 16 GB of RAM. If you're on an older install that inherited the 50% default, you can cap it manually (see Best Practices below).

If a scrub reports checksum errors that keep coming back on the same disk even after a scrub completes, treat that disk as failing regardless of what SMART says. ZFS's own checksum detection is more sensitive to early degradation than most SMART attributes.

Best Practices

Use mirrors for anything holding VM disks. VMs generate a lot of small, random reads and writes, and mirrors handle that pattern far better than RAIDZ, which is built more for sequential throughput. RAIDZ is a better fit for bulk storage — media libraries, backup targets, that sort of thing.

Always build pools using /dev/disk/by-id/... paths, never /dev/sda or /dev/sdb. Device letters can shuffle around on reboot, especially after adding or removing drives, and importing a pool with the wrong disk in the wrong slot is a bad time.

Leave headroom. ZFS performance falls off noticeably once a pool passes about 80% full, and it gets worse the closer you get to 100%. If you're planning capacity, budget for that buffer up front rather than discovering it later.

Cap ARC if your host is memory-constrained. Add a line like options zfs zfs_arc_max=4294967296 (4 GiB, in bytes) to /etc/modprobe.d/zfs.conf, then run update-initramfs -u and reboot for it to take effect.

Don't run ZFS on top of a hardware RAID controller. Let ZFS see the raw disks directly — that's the entire mechanism its self-healing depends on.

ECC RAM is a nice-to-have, not a requirement. You'll see this argued endlessly on forums. Non-ECC RAM works fine for ZFS in practice; ECC just gives you an extra layer of protection against memory errors corrupting data before it's ever written to disk. If you're buying new hardware and ECC is affordable, take it. If you already own the box, don't panic about it.

Frequently Asked Questions

Do I need multiple disks to use ZFS? No. You can run ZFS on a single disk, and you'll still get checksums, snapshots, and compression. You just lose automatic repair of corrupted data, since there's no redundant copy to pull a good block from.

Is ZFS slower than ext4? For raw sequential writes, sometimes, especially without compression. In real Proxmox usage with lz4 compression on, most people don't notice a difference, and some workloads are actually faster since there's less data physically hitting the disk.

Can I convert an existing ext4 install to ZFS? Not in place. You'd need to back up your VMs, reinstall Proxmox with ZFS selected during setup, and restore. There's no in-place conversion path.

What's the difference between RAIDZ1 and a mirror? A mirror keeps a full duplicate copy on each disk and tolerates losing any one disk per mirror. RAIDZ1 spreads parity across all disks in the vdev and also tolerates one disk failure, but with better usable capacity and worse random I/O performance than a mirror of the same disk count.

Does ZFS need a lot of RAM to run? It needs some, mainly for ARC, but the default limits on modern Proxmox versions are conservative enough to run comfortably on a homelab box with 8-16 GB of RAM.

Conclusion

ZFS looks intimidating in the installer mostly because of unfamiliar vocabulary — vdevs, ARC, RAIDZ. Once you've actually looked at a running pool with zpool status and zfs list a few times, none of it feels mysterious anymore. What you're left with is a storage system that catches corruption other filesystems can't see, snapshots in seconds, and gives you real RAID protection without a hardware controller. For a Proxmox host, that's a hard combination to pass up.