Samba 和 luks 一起加密磁碟：儘管 CPU 資源充足，但性能損失巨大，單獨 LUKS 和 samba 可以按預期工作

設置：使用 luks aes-xts 512 位（256 位 AES 密鑰）加密的 SSD，ext4 文件系統

dd 寫入性能138 MB/s，CPU 使用率 97-100 %

dd if=/dev/zero of=testfile status=progress bs=32M count=128
4294967296 bytes (4,3 GB, 4,0 GiB) copied, 31 s, 138 MB/s
128+0 Datensätze ein
128+0 Datensätze aus
4294967296 bytes (4,3 GB, 4,0 GiB) copied, 31,0463 s, 138 MB/s

dd 讀取性能110 MB/s，CPU 使用率從 > 90 % 開始，然後下降到大約 50-60 %，然後在文件讀取結束時再次上升到 > 90 %。

#crop cache before
sudo sh -c "echo 1 > /proc/sys/vm/drop_caches"

現在進行測試：

dd if=testfile of=/dev/null status=progress bs=32M
4261412864 bytes (4,3 GB, 4,0 GiB) copied, 39 s, 109 MB/s
128+0 Datensätze ein
128+0 Datensätze aus
4294967296 bytes (4,3 GB, 4,0 GiB) copied, 39,1345 s, 110 MB/s

現在讓我們仔細看看 samba：

在上面基準測試的磁碟上將1 GB 文件寫入****samba共享大約73 MB/s，CPU 使用率僅為 70% 左右。

從samba共享中****讀取1 GB 文件的速度僅為64 MB/s左右，CPU 使用率約為 55%。還要看這張圖：它開始緩慢，然後速度上升和下降，產生某種波形。

立即再次複製此文件，當它在記憶體中時，它會以****112 MB/s 的速度複製，因此應有全 GigabitEthernet 速度。

---

與未加密的驅動器相比：

dd 寫入速度133 MB/s

dd 讀取速度207 MB/s

Samba 寫入：112 MB/s

Samba 讀取速度：112 MB/s

---

所以單獨使用LUKS加密就可以提供足夠的速度，單獨使用Samba也有足夠的速度。結合起來，性能會大幅下降，而僅使用 dd 時仍有大量可用的 CPU 資源可用。

這裡有什麼問題？為什麼在使用 dd 對 samba 進行操作時，CPU 沒有完全使用？可以做些什麼來使用 smb 和 luks 加密來獲得完整的性能/CPU 使用率？

我已經深入探勘了它。

這似乎是 CPU 使用率的錯誤顯示。

使用 samba 從未加密的驅動器讀取速度為 112 MB/s，需要整個系統上大約 38% 的 CPU 使用率

CPU 使用率在 29% 之間浮動，有時甚至在從未加密的驅動器讀取時很快上升到 94%。

現在將 110 MB/s 的加密讀取性能降低 38 %，得到 68.2 MB/s。這非常接近 64 MB/s。

所以從邏輯的角度來看：Samba 本身需要相對較多的 CPU，並且結合加密所產生的速度現在似乎是有意義的。

順便說一句：完成這些測試的系統是具有 4 核臂 CPU @ 預設時鐘為 1.8 GHz 的 Rasperry PI 400。cryptsetup benchmark報告具有 512 位密鑰（即 256 位 AES 加密）的 aes-xts 77 MB/s 用於加密和 66.9 MB/s 用於解密。然而 cryptsetup 只使用一個 CPU 進行這些測試，所以我猜電源管理會降低 CPU 的時鐘頻率，這就是為什麼真正的加密和解密有更多的性能，如 dd 顯示。

我還做了一些其他的性能測試。

我還將 /dev/mapper 和 /dev/sdd 的預讀大小從 256 增加到 65536 via sudo blockdev --setra 65536 /dev/sdd，sudo blockdev --setra 65536 /dev/mapper/sdd_crypt但是這些並沒有產生任何明顯的區別。

深入探勘我發現這篇非常有趣的文章https://blog.cloudflare.com/speeding-up-linux-disk-encryption/

他們的研究導致no_read_workqueue並no_write_workqueue開始於核心版本 5.9。幸運的是，目前的 Rasperry PI OS 是 5.10.11-v7l+，所以 dmcrypt 支持這些選項。

但是 Raspberry PI OS Buster 上的最新 cryptsetup 版本 2.1.0 不支持這些選項。所以我編譯了 cryptsetup 2.3.4 以使用 no_read_workqueue 和 no_write_workqueue （參見 https://www.kernel.org/doc/html/latest/admin-guide/device-mapper/dm-crypt.html）並通過

cryptsetup open --perf-no_read_workqueue --perf-no_write_workqueue /dev/sdd sdd_crypt

但是，在從設備而不是 RAM 磁碟讀取此特定設置時，性能會大大降低。

結論：由於得到的速度是合理的，它似乎是 CPU 使用率的錯誤顯示。

引用自：https://serverfault.com/questions/1054581