在 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+壓縮
另一個特別要注意的是，LZ4 在不可壓縮資料上的效能非常高。它透過合併「早期中止」機制來實現這一點，如果 LZ4 無法滿足預期的最小壓縮比（ZFS 上為 12.5%），則該機制將觸發。
為了測試，我從我的文件系統創建了一個文字檔find / >> tree.txt。
將檔案複製到兩個資料集然後zpool get dedupratio返回後：
NAME PROPERTY VALUE SOURCE
tank dedupratio 1.00x -
Dedup 實際上是此寫入鏈中的最後一部分。選擇不同的壓縮演算法將導致去重率較差！
不幸的是我的 ZoL 版本不支援加密。但似乎加密不同的資料集也可能會破壞重複資料刪除。加密訊息：https://docs.oracle.com/cd/E53394_01/html/E54801/gkkih.html