ZFS 發送 1.6GB 卷會產生一個巨大的文件 - 應該歸咎於碎片嗎？

我有一個以前從未見過的奇怪問題。我有一個 ZFS 卷，它報告它的大小約為 1.7Gb，快照也是如此。如果我然後嘗試為備份目的進行 zfs 發送，我會得到一個巨大的文件 - 我的自動備份 gzip 後生成一個 12Gb 的文件，當我剛剛進行測試時（沒有 gzip）我在文件增長到後中止了66Gb - 這表明有很多重複數據。這裡發生了什麼？碎片化？如果是這樣，該怎麼辦？

# zpool list
NAME   SIZE  ALLOC   FREE  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
lxd    476G  64.8G   411G         -    60%    13%  1.00x  ONLINE  -

體積：

# zfs list
NAME                                                                                  USED  AVAIL  REFER  MOUNTPOINT
lxd                                                                                  64.8G   396G    24K  none
...
lxd/containers/cdinspector                                                            993M  1.32G  1.68G  /var/snap/lxd/common/lxd/storage-pools/lxd/containers/cdinspector

快照：

# zfs list -t snapshot
NAME                                                                                           USED  AVAIL  REFER  MOUNTPOINT
lxd/containers/cdinspector@test                                                               1.39M      -  1.68G  -

列表-r

# zfs list -r lxd/containers/cdinspector
NAME                         USED  AVAIL  REFER  MOUNTPOINT
lxd/containers/cdinspector  1.05G  1.31G  1.69G  /var/snap/lxd/common/lxd/storage-pools/lxd/containers/cdinspector

用於流式傳輸卷的命令：

# zfs send lxd/containers/cdinspector@test | /usr/bin/mbuffer -m 500M > /backup/test

問題的根源在於 ZFS 壓縮。有問題的客戶端在其容器中執行了一個殭屍 vim 程序，該程序不斷將重複數據寫入 swp 文件。

ZFS 壓縮確實有效！事實證明，消耗的邏輯空間約為 2.4Tb，壓縮比高達 1700 倍，然後 ZFS 將其減少到大約 1.7Gb 物理空間。

有關準確描述該問題的文章，請參閱：

https://utcc.utoronto.ca/~cks/space/blog/solaris/ZFSCompressionAndQuotas

我們現在也在考慮禁用 zfs 壓縮，因為由於我們設計事物的方式，這是對我們進行潛在 DOS 攻擊的一種途徑（儘管這是一種非常緩慢、相當隱蔽的攻擊，需要我們不要注意）。

引用自：https://unix.stackexchange.com/questions/535807