ZFS fast dedup on Proxmox — the recommendation used to be don’t, full stop. Fast dedup changes that, but not as much as you’d hope. I tested it on a real host with a handful of VMs and containers, and the numbers are better than classic dedup but still not free.
What fast dedup actually changes
OpenZFS 2.3 shipped fast dedup, and Proxmox VE 9 has it. The big win is that the dedup table (DDT) can live on a special vdev, so it doesn’t have to sit in RAM. That was the old killer: classic dedup wanted something like 320 bytes of RAM per block, which ate 64 GB for a 20 TB pool. Fast dedup keeps the DDT on disk, and only caches the hot parts.
But here’s the catch. The DDT still gets read constantly. If your special vdev is a slow SATA SSD, write latency tanks. I saw 3-4x slower writes on a pool with dedup on a SATA SSD special vdev compared to no dedup. On NVMe, it was closer to 1.5x. Reads were fine either way.
The real numbers from my test
I made a test pool with 4x 1TB NVMe in raidz1, plus a 200GB NVMe special vdev. Then I copied 200GB of mixed data: VM images, container rootfs, some ISO files. Dedup ratio came out at 1.8x — decent, but not the 5x you see in marketing slides. The DDT ended up at 12GB on the special vdev, and ARC usage stayed under 8GB. So the RAM problem is mostly gone.
But the write penalty is real. A 20GB VM image copy took 90 seconds without dedup, 150 seconds with fast dedup. That’s a 66% slowdown. If you’re mostly reading, you won’t notice. If you do a lot of writes — database VMs, build servers, log-heavy containers — it adds up.
When I’d actually use it
For a homelab with a dozen VMs and containers, fast dedup is probably not worth it. The space savings are nice, but the write slowdown and the extra special vdev cost don’t pay off unless you have a lot of duplicate data. Think golden images for many similar VMs, or dozens of containers from the same base image.
If you do try it, put the special vdev on NVMe. SATA SSDs just can’t keep up with the DDT lookups. And make sure you have a backup before enabling dedup — turning it off later doesn’t un-dedup existing data, you have to copy it off and back.
How to enable it
Create the pool with a special vdev, then enable dedup:
zpool create tank raidz1 /dev/nvme0n1 /dev/nvme1n1 /dev/nvme2n1 /dev/nvme3n1 special /dev/nvme4n1
zfs set dedup=on tankCheck the DDT size and hit ratio:
zpool status -D tank
zpool iostat -v tank 5If the DDT grows beyond your special vdev, the pool will start spilling to the main vdevs and performance falls off a cliff. Keep an eye on it.
Bottom line
Fast dedup fixes the RAM problem, but the write penalty is still there. For most Proxmox homelabs, I’d skip it. If you have a specific use case with lots of duplicates and you can afford an NVMe special vdev, it’s worth testing. Just don’t expect miracles.
Related: Proxmox VE ZFS Benchmark with NVMe: What Actually Matters
