web-dev-qa-db-ja.com

Linuxの圧縮と重複排除の順序に関するzfs

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.

しかし、それが真実である場合、重複排除は、異なる圧縮アルゴリズムで圧縮されたブロックを重複排除しません。

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リストの出力:

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  -

同じファイルを別のデータセットにコピーした後、dedup-ratioは2.0になります。私の意見では、これは、圧縮と暗号化の前にdataブロックで重複除去が行われることを意味します。

これが正しいかどうか誰かが確認できますか?

5
Martin Seitl

http://docs.Oracle.com/cd/E36784_01/html/E36835/gkknx.html が正しいことがわかりました。

ファイルが書き込まれると、データが圧縮、暗号化され、チェックサムが検証されます。次に、可能であれば、データは重複排除されます。

ランダムファイルに関する私の仮定は正しくありませんでした。特定の最小圧縮率を達成できない場合、ZFSは圧縮を中止するようです。

https://wiki.illumos.org/display/illumos/LZ4+Compression からの引用

注意すべきもう1つの特別な点は、非圧縮性データに対する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

5
Martin Seitl