![为什么 LUKS 加密下的 XFS 这么慢(三星 980 PRO SSD)](https://linux22.com/image/200527/%E4%B8%BA%E4%BB%80%E4%B9%88%20LUKS%20%E5%8A%A0%E5%AF%86%E4%B8%8B%E7%9A%84%20XFS%20%E8%BF%99%E4%B9%88%E6%85%A2%EF%BC%88%E4%B8%89%E6%98%9F%20980%20PRO%20SSD%EF%BC%89.png)
我尝试使用默认设置测量 XFS 文件系统上 LUKS/dm-crypt 加密的开销。事实证明,在配备三星 980 PRO SSD(NVME 品种)的笔记本电脑上,git status
与原始分区相比,巨大树(cromium checkout)的开销变慢了 15-20%,而tar xf
扩展到相应树的开销则变慢了 25-25%。 30%。对于 ext4,速度减慢为git status
8% 和 20%,对于 btrfs,速度减慢为 10% 和 17%。这是在 Fedora 和 5.14.10 内核下。
Cloudflare 博客提到了现在可用于调整加密性能的 2 个新选项(--perf-no_read_workqueue、--perf-no_write_workqueue for cryptsetup),但就我而言,它们减慢了速度。无论如何,它都不会解释 XFS 和其他文件系统之间的差异。那么,是什么让 XFS 特别容易受到 LUKS 开销的影响呢?
答案1
事实证明,该问题是由 Fedora 上的 LUKS 设置默认使用 512 字节扇区引起的。按照建议将其增加到 4K红迪网使用 --perf-no_read_workqueue 选项cryptsetup open --type=luks
足以将 XFS 的 LUKS 加密开销减少到 7-9%。
出现 512 的原因是 Samsung 980 PRO 默认报告该值,Fedora 35 与此相符。