Feature Request: Allow Safe Removal of Unused Dedup VDEVs (OpenZFS #17194)

Hi all,

I wanted to bring attention to a real-world usability issue with ZFS that recently affected my TrueNAS setup.

I accidentally added a dedup vdev mirror to one of my production pools — intending to experiment on a separate pool — but never enabled dedup=on on any datasets. After realizing the dedup vdev was completely unused, I discovered there’s no way to remove it without destroying and recreating the entire pool.

Even when the DDT is empty (zdb -DD confirms this) and dedup=off is set pool-wide, the dedup vdev is permanently part of the pool.

This kind of mistake feels far too easy to make (especially with the new vdev class support exposed in SCALE 24.10+), and the consequences are frustrating — especially for users with limited storage flexibility or long-lived pools. In my case, backing up and restoring isn’t an option as the accidental Dedup VDEV is now tied to my media zpool which is over 150 TB. Remediating this would be no trivial thing. I’d also like to not waste the expensive flash that was intended for another pool for VMs.

I’ve submitted a feature request upstream to OpenZFS: [GitHub Issue #17194 – Allow Safe Removal of Unused Dedup VDEVs]

I’m sharing it here in case others have run into the same issue, and to request that iXsystems consider supporting or advocating for this upstream — and potentially improving UX safeguards or rollback paths in the TrueNAS interface.

Thanks!

Was your production pool Mirrors or RaidZ of any kind?
Usually vdevs can be removed if the main pool is mirrors, but not RaidZ

Creating a pool checkpoint before you added the vdev would have allowed you to rewind.

I’m as curious as @NugentS, since I believe vdev removal is supported, even for a special vdev, as long as everything are stripes or mirrors.

I unfortunately didn’t know about the pool checkpoint thing. Good to know for next time.

Also, unfortunately, my data vdev is RAIDz2. Special device and slog are mirrors but I assume that won’t help here.

You cannot remove the special vdev if that’s the case. :slightly_frowning_face:

Yes I am aware. Hence my ask for there to be the ability to do so. :blush:

Since there is zero data on it and dedup has never been turned on, there should be a safe way to remove it.

I agree it should be possible to do…

but, then its a case of priorities and the business case for developers to add seat-belts for rare issues, is not that good. If OpenZFS support it, that is great.