在加密卷上使用壓縮文件系統會提高性能嗎？

加密/解密通常是訪問加密卷時的主要瓶頸。使用具有快速透明壓縮（例如 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

我做了一個小基準測試。它只測試寫入。

測試數據是一個Linux核心原始碼樹（linux-3.8），已經解壓到記憶體（/dev/shm/tmpfs），所以應該盡量少受數據源的影響。我在此測試中使用了可壓縮數據，因為無論加密如何，使用不可壓縮文件進行壓縮都是無稽之談。

在 LUKS 上的 4GiB LVM 卷上使用 btrfs 文件系統

$$ aes, xts-plain, sha256 $$，在 RAID-5 上超過 3 個具有 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要快一點，而且總的來說，不值得費心（考慮到我在此測試中使用了易於壓縮的數據，差異對我來說太小了）。

我也會做一個讀取測試，但它更複雜，因為你必須處理記憶體。

引用自：https://unix.stackexchange.com/questions/68879