Вот тут человек подписался в полном незнании того, как это работает.

Chunks of data are remembered in a table of some sort that maps the data's checksum to its storage location and reference count. When you store another copy of existing data, instead of allocating new space on disk, the dedup code just increments the reference count on the existing data. When data is highly replicated, which is typical of backup servers, virtual machine images, and source code repositories, deduplication can reduce space consumption not just by percentages, but by multiples.

Профит может быть такой как от сжатия, если входные данные - разношёрстный зоопарк. И в разы лучше, если это например ежедневные бекапы компании за последний год.

...

Most dedup solutions only work on a limited amount of data -- a handful of terabytes -- because they require their dedup tables to be resident in memory.

ZFS places no restrictions on your ability to dedup. You can dedup a petabyte if you're so inclined. The performace of ZFS dedup will follow the obvious trajectory: it will be fastest when the DDTs (dedup tables) fit in memory, a little slower when they spill over into the L2ARC, and much slower when they have to be read from disk. The topic of dedup performance could easily fill many blog entries -- and it will over time -- but the point I want to emphasize here is that there are no limits in ZFS dedup. ZFS dedup scales to any capacity on any platform, even a laptop; it just goes faster as you give it more hardware.

Расходы - на посчитать чексум, найти копию в таблице (при условии что таблица не вытеснена из ОЗУ - копейки), сделать запись о дубле - сами дублируемые данные при этом не пишутся (если конечно ты сам не настроил делать несколько копий блоков, чтобы исключить bad blocks - что не есть хорошо, для этого лучше делать зеркало средствами ZFS на другой винт)