在 Linux 上的 zfs 上，数据写入 zfs 文件系统的顺序是什么？
我在http://docs.oracle.com/cd/E36784_01/html/E36835/gkknx.html说；When a file is written, the data is compressed, encrypted, and the checksum is verified. Then, the data is deduplicated, if possible.
但如果这是真的，那么 dedup 就不会对使用不同压缩算法压缩的块进行重复数据删除。
我测试了 mysqlf 并且我认为顺序如下：dedup, compress, encrypt。
我的测试设置：
zpool create tank /dev/sdb
zfs create tank/lz4
zfs create tank/gzip9
zfs set compression=lz4 tank/lz4
zfs set compression=gzip-9 tank/gzip9
zfs set dedup=on tank
输出zfs list
NAME USED AVAIL REFER MOUNTPOINT
tank 106K 19,3G 19K /tank
tank/gzip9 19K 19,3G 19K /tank/gzip9
tank/lz4 19K 19,3G 19K /tank/lz4
生成随机文件dd if=/dev/urandom of=random.txt count=128K bs=1024
131072+0 Datensätze ein
131072+0 Datensätze aus
134217728 Bytes (134 MB) kopiert, 12,8786 s, 10,4 MB/s
空池上的 zpool list 的输出：
NAME SIZE ALLOC FREE EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
tank 19,9G 134K 19,9G - 0% 0% 1.00x ONLINE -
然后将文件复制到具有不同压缩算法的数据集：
cp random.txt /tank/lz4
cp random.txt /tank/gzip9
复制后的输出zfs list：
NAME USED AVAIL REFER MOUNTPOINT
tank 257M 19,1G 19K /tank
tank/gzip9 128M 19,1G 128M /tank/gzip9
tank/lz4 128M 19,1G 128M /tank/lz4
zpool list复制后的输出：
NAME SIZE ALLOC FREE EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
tank 19,9G 129M 19,7G - 0% 0% 2.00x ONLINE -
重复数据删除率为2.0将同一文件复制到不同的数据集后。在我看来，这意味着重复数据删除是在数据- 压缩和加密之前的块。
请有人验证一下这是否正确吗？
答案1
事实证明，http://docs.oracle.com/cd/E36784_01/html/E36835/gkknx.html是对的。
写入文件时，数据会被压缩、加密，并验证校验和。然后，如果可能的话，对数据进行重复数据删除。
我对随机文件的假设是错误的。似乎如果 ZFS 无法达到某个最小压缩率，它就会中止压缩。
引自https://wiki.illumos.org/display/illumos/LZ4+Compression
另一件需要特别注意的事情是，LZ4 在不可压缩数据上的性能非常高。它通过引入“早期中止”机制来实现这一点，如果 LZ4 无法满足预期的最低压缩率（ZFS 上为 12.5%），则会触发该机制。
为了测试，我从文件系统创建了一个文本文件find / >> tree.txt。
将文件复制到两个数据集后zpool get dedupratio确实返回：
NAME PROPERTY VALUE SOURCE
tank dedupratio 1.00x -
重复数据删除实际上是此写入链中的最后一部分。选择不同的压缩算法将导致重复数据删除效果不佳！
不幸的是，我的 ZoL 版本不支持加密。但似乎加密不同的数据集也会破坏重复数据删除。加密信息：https://docs.oracle.com/cd/E53394_01/html/E54801/gkkih.html