☰

암호화된 볼륨에서 압축 파일 시스템을 사용하면 성능이 향상됩니까?

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일반적으로 신경 쓸 가치가 없습니다(이 테스트에서 쉽게 압축할 수 있는 데이터를 사용했다는 점을 고려하면 차이는 내 취향에 비해 너무 작습니다).

읽기 테스트도 해보고 싶지만 캐싱을 처리해야 하기 때문에 더 복잡합니다.

관련 정보