☰

ZFS 发送 1.6GB 卷会产生一个巨大的文件 - 碎片是罪魁祸首？

tag-icon • tag-icon zfs snapshot
ZFS 发送 1.6GB 卷会产生一个巨大的文件 - 碎片是罪魁祸首？

我有一个以前从未见过的奇怪问题。我有一个 ZFS 卷，报告其大小约为 1.7Gb，快照也是如此。如果我随后尝试执行 zfs send 进行备份，我会得到一个巨大的文件 - 我的自动备份经过 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

答案1

事实证明，该问题的根源在于 ZFS 压缩。相关客户端的容器中运行着一个僵尸 vim 进程，该进程不断将重复的数据写入 swp 文件。

ZFS 压缩确实有效！事实证明，消耗的逻辑空间约为 2.4Tb，压缩比高达 1700 倍，ZFS 将其减少到约 1.7Gb 物理空间。

有关准确描述该问题的文章，请参阅：

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

我们现在也在考虑禁用 zfs 压缩，因为由于我们设计的方式，这是对我们进行潜在 DOS 攻击的一个途径（尽管这是一种非常缓慢、相当模糊的攻击，需要我们不去注意）。

相关内容