今天因为某些缘故将一个大文件从NAS的 HDD pool 复制到 SDD pool，然后文件复制到大约10GB时速度突然降低到了1MB以下。
感觉可能与 dedup 相关，又在 SSD pool 创建一个关闭 dedup 的 dataset。再次测试，一切正常，没有再出现降速的问题。

虽然关了 dedup 就完事，但为什么会这样呢？
到 Arch 群里询问了一下，文件系统专家fc老师如此回答：『我博客分析過 zfs dedup 的原理。基本上是把每個讀操作變成 3 個隨機地址的讀操作+1個寫操作，非常消耗 iops ，即便你 arc 開得夠大也需要夠快（iops層面）的存儲設備支撐』。

fc老师对zfs dedup的个人看法是：『zfs dedup 算是 sun 倒下之前新加的東西，我覺得還沒做到商業方案級別的成熟度就開源了 ，然後 sun 就沒了』。

之后到fc老师博客，将两篇讲解ZFS的长篇博文读完。
https://farseerfc.me/zhs/zfs-layered-architecture-design.html
https://farseerfc.me/zhs/btrfs-vs-zfs-difference-in-implementing-snapshots.html

ZFS dedup 确实就是个坑，收益不大，但IO带宽、内存占用巨大。

另外，在 Truenas 上开启 ZFS Deduplication 选项时提示：This feature is memory-intensive and **permanently affects how the data is stored.**
我对这里的 permanently affects 有一些担心，于是又请教了fc老师。
fc老师的回答：『關掉之後，之前開著的時候寫入的數據還是處於 dedup 的 DDT 裡，它們在被刪掉之前持續消耗額外的資源包括內存』。

一番对话下来，我的内心是这样的

#zfs

@bgme 我的理解和經驗是：根據系統效能狀況開啓壓縮功能，dedup 的話一般沒有必要開啓。

@SakuragawaAsaba
新的问题来了，压缩算法选什么，压缩级别应该怎么选。