在加密卷上使用压缩文件系统是否可以提高性能？

我做了一个小的基准测试。它只是测试写。

测试数据是一个Linux内核源树（linux-3.8），已经解压缩到内存（/ dev / shm / tmpfs）中，因此数据源的影响应尽可能小。我使用可压缩数据进行此测试，因为无论加密如何，使用不可压缩文件进行压缩都是毫无意义的。

在4块LVM卷上的LUKS [aes，xts-plain，sha256]的RAID-5上的3tr磁盘上使用btrfs文件系统，块大小为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

因此，在每次迭代中，它都会创建一个新的文件系统，并测量从内存和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快一点，一般，不值得费心（不同的是对我的口味太小了，考虑到我以前容易压缩的数据本次测试）。

我也会进行一次读取测试，但由于您必须处理缓存，因此它更加复杂。