From a0f2ff667c2b45d766677255a847fe8820d8e144 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?J=C3=B6rg=20Thalheim?= Date: Mon, 7 Sep 2026 07:59:26 +0200 Subject: [PATCH] README: document FIDEDUPERANGE on preexisting pools Users asked (#42) whether pools created before FIDEDUPERANGE need migration. They do not: it is an ioctl, not a pool feature, and only relies on block_cloning. Closes #42 --- README.md | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/README.md b/README.md index 3c13d17..8d8ad18 100644 --- a/README.md +++ b/README.md @@ -79,6 +79,27 @@ modify your data while `zfs-dedup` runs. The fallback also bumps the mtime of deduped files, because ZFS treats a clone as a write. `FIDEDUPERANGE` leaves timestamps untouched. +## Existing pools + +`FIDEDUPERANGE` is only a new ioctl in the kernel module. It adds no +pool feature flag and does not change the on-disk format. It uses the +same `block_cloning` feature `FICLONERANGE` has used since 2.2. For a +pool created before that: + +- Enable `feature@block_cloning` (`zpool upgrade` or + `zpool set feature@block_cloning=enabled `). Pools without it + are skipped. +- On 2.2.1 through 2.2.x set the `zfs_bclone_enabled=1` module + parameter. It defaults to on since 2.3.0. +- Blocks written before the feature was enabled clone fine, no rewrite + needed. +- Encrypted datasets can only clone into each other when they share + the same master key, i.e. the same encryption root. + +Once your ZFS includes openzfs/zfs#18745, zfs-dedup detects +`FIDEDUPERANGE` automatically and `--force` is no longer needed. The +hash cache from earlier runs stays valid. + ## Memory zfs-dedup needs roughly 240 MiB per million files in the largest dataset