☰

暗号化されたボリュームで圧縮ファイルシステムを使用するとパフォーマンスが向上しますか？

tag-icon • tag-icon filesystems encryption compression btrfs dm-crypt
暗号化されたボリュームで圧縮ファイルシステムを使用するとパフォーマンスが向上しますか？

暗号化/暗号解読は、暗号化されたボリュームにアクセスする際に主なボトルネックになることがよくあります。高速透明圧縮（例：BTRFS + LZO）機能を備えたファイルシステムを使用すると便利ですか？暗号化する必要があるデータの量が減り、圧縮が暗号化アルゴリズムよりもはるかに速い場合、全体の処理時間が短縮されるという概念です。

修正する:Matが指摘したように、これは実際のデータの圧縮可能性に依存します。もちろん、ソースコードやドキュメントのように圧縮可能であるとします。もちろん、メディアファイルに使用することは意味がありません。 （しかしあまり悪いようではありません。BTRFSは圧縮できないファイルを検出しようとします。.)

このアイデアをテストするのは時間がかかるプロセスなので、すでにこれについて経験がある方がいるかどうか尋ねたかったです。非常に簡単な設定だけをテストしましたが、違いがあるようです。

$ touch BIG_EMPTY
$ chattr +c BIG_EMPTY
$ sync ; time ( dd if=/dev/zero of=BIG_EMPTY bs=$(( 1024*1024 )) count=1024 ; sync )
...
real    0m26.748s
user    0m0.008s
sys 0m2.632s

$ touch BIG_EMPTY-n
$ sync ; time ( dd if=/dev/zero of=BIG_EMPTY-n bs=$(( 1024*1024 )) count=1024 ; sync )
...
real    1m31.882s
user    0m0.004s
sys 0m2.916s

答え1

簡単なベンチマークテストをしてみました。ただし、書き込みのみテストします。

テストデータはLinuxカーネルソースツリー（linux-3.8）であり、メモリ（/dev/shm/tmpfs）に解凍されているため、データソースの影響はできるだけ小さくする必要があります。圧縮できないファイルを使用して圧縮することは暗号化に関係なく意味がないため、今回のテストでは圧縮可能なデータを使用しました。

4GiB LVMボリュームでのbtrfsファイルシステムの使用、LUKS [aes、xts-plain、sha256]、3つのディスクのRAID-5（64kbブロックサイズ）。 CPUはAES-NIなしのIntel E8400 2x3Ghzです。カーネルは3.8.2 x86_64です。

スクリプト：

#!/bin/bash

PARTITION="/dev/lvm/btrfs"
MOUNTPOINT="/mnt/btrfs"

umount "$MOUNTPOINT" >& /dev/null

for method in no lzo zlib
do
    for iter in {1..3}
    do
        echo Prepare compress="$method", iter "$iter"
        mkfs.btrfs "$PARTITION" >& /dev/null
        mount -o compress="$method",compress-force="$method" "$PARTITION" "$MOUNTPOINT"
        sync
        time (cp -a /dev/shm/linux-3.8 "$MOUNTPOINT"/linux-3.8 ; umount "$MOUNTPOINT")
        echo Done compress="$method", iter "$iter"
    done
done

したがって、各反復で新しいファイルシステムを作成し、メモリからLinuxカーネルソースコードをコピーして削除するのに必要な時間を測定します。したがって、これは純粋な書き込みテストであり、読み取りはありません。

結果：

Prepare compress=no, iter 1

real 0m12.790s
user 0m0.127s
sys 0m2.033s
Done compress=no, iter 1
Prepare compress=no, iter 2

real 0m15.314s
user 0m0.132s
sys 0m2.027s
Done compress=no, iter 2
Prepare compress=no, iter 3

real 0m14.764s
user 0m0.130s
sys 0m2.039s
Done compress=no, iter 3
Prepare compress=lzo, iter 1

real 0m11.611s
user 0m0.146s
sys 0m1.890s
Done compress=lzo, iter 1
Prepare compress=lzo, iter 2

real 0m11.764s
user 0m0.127s
sys 0m1.928s
Done compress=lzo, iter 2
Prepare compress=lzo, iter 3

real 0m12.065s
user 0m0.132s
sys 0m1.897s
Done compress=lzo, iter 3
Prepare compress=zlib, iter 1

real 0m16.492s
user 0m0.116s
sys 0m1.886s
Done compress=zlib, iter 1
Prepare compress=zlib, iter 2

real 0m16.937s
user 0m0.144s
sys 0m1.871s
Done compress=zlib, iter 2
Prepare compress=zlib, iter 3

real 0m15.954s
user 0m0.124s
sys 0m1.889s
Done compress=zlib, iter 3

zlibかなり遅く、少し速く、一般的lzoに気にする価値はありません（このテストで簡単に圧縮できるデータを使用したことを考慮すると、違いは私の好みに比べて小さすぎます）。

読み取りテストもしたいのですが、キャッシュを処理する必要があるため、より複雑です。

関連情報