我选择Linux桌面上的存储加密解决方案。多年来，LUKS 上的 LVM 一直是具有卓越性能和可靠性的最佳选择。但 Linux 上的 ZFS 积极开发新功能，现在我们有了选择。
我将 LUKS 和 ZFS 上的 LVM 与具有默认加密设置的各种 fio 测试进行了比较，这些测试由开发人员和维护人员提供：LUKS 的 aes-xts-512b、ZFS 的 aes-256-gcm。以下是每种卷类型的 RAM 块设备的平均带宽和延迟指标：
乍一看，图表上的比较似乎存在争议。在随机小块上，XTS 明显快于 GTC。但在连续读取和写入时，ZFS 显示出相当的延迟，并且带宽显着增加！
就性能而言，以下哪种解决方案最适合桌面任务？现在我发现很难选择，我将感谢您的建议。
UPD1：
例如，我的典型存储任务是：
- Web 浏览器加载：在本地缓存中混合读取和写入接近 100-1000 KB 的文件；
- 启动应用程序：随机读取接近100-1000 KB的系统二进制文件；
- 编译软件：读写大量小文件；
- 存储像照片这样的档案：大部分写入的文件最大为 10 MB，很少读取；
- 为家庭媒体提供超高清视频等大文件：高达 100 GB 的连续写入或读取；
- 和更多。
针对每个单独的任务优化系统很容易。但哪种解决方案最适合所有这些问题呢？
UPD2：
以下是一些现实生活中的文件测量结果：
答案1
在 LUKS 和 ZFS 加密之间，我选择了 ext4 的 fscrypt。
Fscrypt 在某些方面提供的保护稍弱：
- 它暴露文件元数据：现有的事实、大小、目录中的文件计数。
- 它不能用于整个根加密：敏感数据可能会在系统日志或文件索引中泄漏。交换加密需要额外的步骤。
- 在某些配置中，其加密可能取决于弱哈希系统密码在阴影中。但为此目的，现代发行版正在用更安全（fixme）的 yescrypt 算法取代 sha512。
另一方面，fscrypt 为数据提供 aes-256-xts 加密，为文件名提供 aes-256-cts 加密，具有近线加密速度：
如果 fscrypt 限制适合您的威胁模型，那么就吞吐量和延迟而言，它是最佳解决方案。