☰

1.6GBボリュームを転送するZFSは、巨大なファイルを生成します。断片化が原因ですか？

tag-icon • tag-icon zfs snapshot
1.6GBボリュームを転送するZFSは、巨大なファイルを生成します。断片化が原因ですか？

以前見たことのない奇妙な問題があります。約1.7Gbのサイズを報告するZFSボリュームがあり、スナップショットも同じです。その後、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

答え1

問題の根本的な原因はZFS圧縮であることがわかりました。関連クライアントのコンテナにはゾンビvimプロセスが実行されており、このプロセスはswpファイルに冗長データを継続的に記録します。

ZFS圧縮は実際に動作します！消費された論理空間は約2.4 Tb、圧縮率は最大1700倍、ZFSはこれを物理空間の約1.7 Gbに減らします。

問題を正確に説明する記事については、次を参照してください。

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

また、zfs圧縮を無効にすることを検討しています。なぜなら、私たちが設計した方法でこれが私たちに対する潜在的なDOS攻撃の通路になるからです（これは私たちが気づかないようにする非常に遅く、やや曖昧な攻撃ですが）。

関連情報