☰

FIOを使う

tag-icon • tag-icon performance encryption luks zfs
FIOを使う

LUKS暗号化パーティションの上にZFSを使用することと、ZFSの基本データセット固有の暗号化を使用することについての議論がありました。ただし、常に 2 つの 1 つまたは 2 つのいずれかの方法で表示されます。

私の質問は、LUKSパーティションを作成し、それをzpoolコンテナとして使用し、そのzpoolにZFS暗号化データセットを生成する両方の方法を使用することです。これは、メタデータの漏洩なしで保存時に暗号化を提供し、暗号化されたzfs sendデータセットを信頼できないバックアップストアに保存するなど、いくつかのきちんとしたトリックを可能にする必要があります。

この場合、この「二重暗号化」はZFS基本暗号化と比較してパフォーマンスにどのような影響を与えますか？

答え1

これについていくつかのテストを行ったので、ここにいくつかの数字があります。これは私が考えることができる最初の側面で測定されることに注意してください。より詳細な情報を含む他の答えが欲しいです。

すべてのテストは、32G RAM、スワップなし、最小ARCサイズ1G、最大ARCサイズ3G（影響を受ける場合）を使用して行われました。

FIOを使う

私はこれを試しましたが、報告されたfio --refill_buffers --rw=randrw --name=test --size=5G --numjobs=5ヘッダー番号は次のとおりです。

ZFS基本データセット暗号化のみ可能

   READ: bw=25.6MiB/s (26.9MB/s), 5252KiB/s-5325KiB/s (5378kB/s-5453kB/s), io=12.5GiB (13.4GB), run=492550-499123msec
  WRITE: bw=25.7MiB/s (26.9MB/s), 5252KiB/s-5320KiB/s (5378kB/s-5447kB/s), io=12.5GiB (13.4GB), run=492550-499123msec

LUKS 暗号化 zpool の ZFS 基本データセットの暗号化

   READ: bw=17.5MiB/s (18.4MB/s), 3589KiB/s-3619KiB/s (3676kB/s-3706kB/s), io=12.5GiB (13.4GB), run=724349-729360msec
  WRITE: bw=17.6MiB/s (18.4MB/s), 3596KiB/s-3619KiB/s (3682kB/s-3706kB/s), io=12.5GiB (13.4GB), run=724349-729360msec

したがって、FIOはかなりの帯域幅の違いを示しています。しかし、実際の使用に近いものを試したいので、ソースからGlasgow Haskell Compiler 9.8.2とLLVM 0e5a53cc01e406436cb7c703c84598e474d635deをコンパイルしてみました。

GHC 9.8.2 コンパイル

Hadrianの組み込みプロファイリングツールを使用して、デフォルト設定と32スレッドを使用して新しいビルドを実行しました。

ZFSのみ

ビルド時間：シリアル3時間30分、並列25分21秒。最も長い単一のビルドルールGHC/Hs/Instances.p_oは1分23秒です。

ZFSはLUKSよりも優れています。

ビルド時間：シリアル3時間34分、並列25分16秒。最も長い単一のビルドルールGHC/Hs/Instances.p_oは1分23秒です。

LLVMのコンパイル

デフォルトフラグを使用して、Ninja Builderは18個のコンパイルスレッドと2個のリンカースレッドを使用します（メモリ不足を防ぐため）。 Ninjaにプロファイリングサポートがあるかどうかわからないので、ただtime。

ZFSのみ

real    61m40.229s
user    542m57.056s
sys     49m29.346s

ZFSはLUKSよりも優れています。

real    61m25.019s
user    542m51.777s
sys     48m58.462s

いくつかのランダムSQLiteベンチマーク

ZFSのみ

fillseq      :      38.833 micros/op;                 
fillseqsync  :    1391.493 micros/op;               
fillseqbatch :       1.954 micros/op;                 
fillrandom   :      62.420 micros/op;                 
fillrandsync :    1406.985 micros/op;               
fillrandbatch :      36.149 micros/op;                
overwrite    :      84.639 micros/op;    1.3 MB/s     
overwritebatch :      68.687 micros/op;               
readrandom   :      58.584 micros/op;                 
readseq      :      42.483 micros/op;                 
fillrand100K :     867.440 micros/op;  1           
fillseq100K  :     851.599 micros/op;  11          
readseq      :       0.461 micros/op;                 
readrand100K :      99.846 micros/op;

ZFSはLUKSよりも優れています。

fillseq      :      38.453 micros/op;                 
fillseqsync  :    1454.040 micros/op;               
fillseqbatch :       2.035 micros/op;                 
fillrandom   :      63.107 micros/op;                 
fillrandsync :    1531.823 micros/op;               
fillrandbatch :      36.717 micros/op;                
overwrite    :      82.490 micros/op;    1.3 MB/s     
overwritebatch :      68.175 micros/op;               
readrandom   :      46.421 micros/op;                 
readseq      :      42.086 micros/op;                 
fillrand100K :     849.366 micros/op;  11          
fillseq100K  :     837.989 micros/op;  11          
readseq      :       0.461 micros/op;                 
readrand100K :      98.598 micros/op;

要するに

FIOの生IO性能だけを見ると、かなりのギャップがあることがわかります。読み取りおよび書き込み帯域幅の両方が約30％減少したようです。ただし、インターリーブされたIOと計算が多い実際の使用では、違いは本質的に消えます。

関連情報