☰

在加密卷上使用压缩文件系统会提高性能吗？

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 卷、LUKS [aes、xts-plain、sha256]、超过 3 个磁盘（块大小为 64kb）的 RAID-5 上使用 btrfs 文件系统。 CPU 是 Intel E8400 2x3Ghz，不带 AES-NI。内核是 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快一点，而且一般来说，不值得打扰（考虑到我在这个测试中使用了易于压缩的数据，对于我的口味来说，差异太小了）。

我也会进行读取测试，但它更复杂，因为您必须处理缓存。

相关内容