web-dev-qa-db-ja.com

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

暗号化されたボリュームにアクセスする場合、暗号化/復号化が主なボトルネックになることがよくあります。高速透過圧縮（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
filesystemsencryptioncompressionbtrfsdm-crypt
6
Petr Pudlák

私は小さなベンチマークを行いました。ただし、書き込みをテストするだけです。

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

4GiB LVMボリューム、LUKS [aes、xts-plain、sha256]、64kbチャンクサイズの3ディスク上のRAID-5でbtrfsファイルシステムを使用します。 CPUは、AES-NIを搭載していないIntel E84002x3Ghzです。カーネルは3.8.2x86_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

したがって、各反復で、新しいファイルシステムを作成し、メモリとumountから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を使用すると、少し速くなります。一般に、気にする価値はありません（圧縮しやすいデータを使用したことを考えると、違いは私の好みには小さすぎます。このテスト）。

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

8
frostschutz