![在加密卷上使用压缩文件系统会提高性能吗?](https://linux22.com/image/30236/%E5%9C%A8%E5%8A%A0%E5%AF%86%E5%8D%B7%E4%B8%8A%E4%BD%BF%E7%94%A8%E5%8E%8B%E7%BC%A9%E6%96%87%E4%BB%B6%E7%B3%BB%E7%BB%9F%E4%BC%9A%E6%8F%90%E9%AB%98%E6%80%A7%E8%83%BD%E5%90%97%EF%BC%9F.png)
加密/解密通常是访问加密卷时的主要瓶颈。使用具有快速透明压缩功能的文件系统(例如 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
快一点,而且一般来说,不值得打扰(考虑到我在这个测试中使用了易于压缩的数据,对于我的口味来说,差异太小了)。
我也会进行读取测试,但它更复杂,因为您必须处理缓存。