O uso de um sistema de arquivos compactado em um volume criptografado melhora o desempenho?

Question

A criptografia / descriptografia costuma ser o principal gargalo ao acessar um volume criptografado. Usar um sistema de arquivos com uma rápida compactação transparente (como BTRFS + LZO) ajuda? A ideia é que haja menos dados para criptografar e, se a compactação for significativamente mais rápida do que o algoritmo de criptografia, o tempo de processamento geral será menor.

Atualização: Como apontado por Mat, isso depende da compressibilidade dos dados reais. Claro, eu suponho que seja compressível, como código-fonte ou documentos. É claro que não tem sentido usá-lo para arquivos de mídia (mas eu acho que não vai doer muito, como BTRFS tenta detectar arquivos incompressíveis .)

Como testar essa ideia é um processo muito demorado, estou perguntando se alguém já tem alguma experiência com isso. Eu testei apenas uma configuração muito simples, e parece mostrar uma diferença:

$ 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

    

Answer 1

Eu fiz um pequeno benchmark. Apenas testa as gravações embora.

Dados de teste são uma árvore de código-fonte do kernel do Linux (linux-3.8), já descompactados na memória (/ dev / shm / tmpfs), portanto, deve haver a menor influência possível da fonte de dados. Eu usei dados compactáveis para este teste, pois a compactação com arquivos não compressíveis é um absurdo, independentemente da criptografia.

Usando o sistema de arquivos btrfs em um volume 4GiB LVM, no LUKS [aes, xts-plain, sha256], no RAID-5 em 3 discos com 64kb chunksize. CPU é um Intel E8400 2x3Ghz sem AES-NI. O kernel é 3.8.2 x86_64.

O script:

#!/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

Então, em cada iteração, ele cria um novo sistema de arquivos e mede o tempo que leva para copiar a origem do kernel do Linux da memória e do umount. Então é um teste de gravação puro, zero lê.

Os resultados:

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

Com zlib é muito mais lento, com lzo um pouco mais rápido e, em geral, não vale a pena (a diferença é pequena demais para o meu gosto, considerando que usei dados fáceis de compactar para esse teste) .

Eu faria um teste de leitura também, mas é mais complicado porque você precisa lidar com o cache.