☰

使用FIO

tag-icon • tag-icon performance encryption luks zfs
使用FIO

关于在 LUKS 加密分区之上使用 ZFS 与使用 ZFS 的本机每数据集加密进行了讨论。然而，它们总是以非此即彼的方式呈现。

我的问题是关于使用两者：创建 LUKS 分区，然后将其用作 zpool 容器，然后在该 zpool 中创建 ZFS 加密的数据集。这应该可以提供无元数据泄漏的静态加密，同时仍然允许使用一些巧妙的技巧，例如zfs send将加密数据集存储到不受信任的备份存储中。

在这种情况下，与仅 ZFS 本机加密相比，这种“双重加密”会对性能产生什么影响？

答案1

我对此做了一些测试，所以这里有一些数字。请记住，这是用我能想到的第一个东西来衡量的；我希望得到更多详细信息的其他答案。

所有测试均使用 32G RAM、无交换、最小 ARC 大小为 1G、最大 ARC 大小为 3G（如果有影响的话）完成。

使用FIO

我已经尝试过fio --refill_buffers --rw=randrw --name=test --size=5G --numjobs=5，报告的标题数字是：

仅 ZFS 本机数据集加密

   READ: bw=25.6MiB/s (26.9MB/s), 5252KiB/s-5325KiB/s (5378kB/s-5453kB/s), io=12.5GiB (13.4GB), run=492550-499123msec
  WRITE: bw=25.7MiB/s (26.9MB/s), 5252KiB/s-5320KiB/s (5378kB/s-5447kB/s), io=12.5GiB (13.4GB), run=492550-499123msec

LUKS 加密 zpool 上的 ZFS 本机数据集加密

   READ: bw=17.5MiB/s (18.4MB/s), 3589KiB/s-3619KiB/s (3676kB/s-3706kB/s), io=12.5GiB (13.4GB), run=724349-729360msec
  WRITE: bw=17.6MiB/s (18.4MB/s), 3596KiB/s-3619KiB/s (3682kB/s-3706kB/s), io=12.5GiB (13.4GB), run=724349-729360msec

因此 FIO 显示出显着的带宽差异。但我想尝试一些更接近现实生活使用的东西，所以我尝试从源代码编译 Glasgow Haskell Compiler 9.8.2 和 LLVM 0e5a53cc01e406436cb7c703c84598e474d635de。

编译 GHC 9.8.2

使用 Hadrian 的内置分析工具，我使用默认设置和 32 个线程运行了一个全新的构建。

仅限 ZFS

构建时间：串行化 3 小时 30 分钟，并行化 25 分 21 秒。最长的单次构建规则GHC/Hs/Instances.p_o为 1 分 23 秒。

ZFS 优于 LUKS

构建时间：串行化 3 小时 34 分钟，并行化 25 分 16 秒。最长的单次构建规则GHC/Hs/Instances.p_o为 1 分 23 秒。

编译LLVM

使用默认标志，Ninja 构建器使用 18 个编译线程和 2 个链接器线程（以避免内存不足）。我不知道 Ninja 是否有任何分析支持，所以我只是使用time.

仅限 ZFS

real    61m40.229s
user    542m57.056s
sys     49m29.346s

ZFS 优于 LUKS

real    61m25.019s
user    542m51.777s
sys     48m58.462s

一些随机的 SQLite 基准测试

仅限 ZFS

fillseq      :      38.833 micros/op;                 
fillseqsync  :    1391.493 micros/op;               
fillseqbatch :       1.954 micros/op;                 
fillrandom   :      62.420 micros/op;                 
fillrandsync :    1406.985 micros/op;               
fillrandbatch :      36.149 micros/op;                
overwrite    :      84.639 micros/op;    1.3 MB/s     
overwritebatch :      68.687 micros/op;               
readrandom   :      58.584 micros/op;                 
readseq      :      42.483 micros/op;                 
fillrand100K :     867.440 micros/op;  1           
fillseq100K  :     851.599 micros/op;  11          
readseq      :       0.461 micros/op;                 
readrand100K :      99.846 micros/op;

ZFS 优于 LUKS

fillseq      :      38.453 micros/op;                 
fillseqsync  :    1454.040 micros/op;               
fillseqbatch :       2.035 micros/op;                 
fillrandom   :      63.107 micros/op;                 
fillrandsync :    1531.823 micros/op;               
fillrandbatch :      36.717 micros/op;                
overwrite    :      82.490 micros/op;    1.3 MB/s     
overwritebatch :      68.175 micros/op;               
readrandom   :      46.421 micros/op;                 
readseq      :      42.086 micros/op;                 
fillrand100K :     849.366 micros/op;  11          
fillseq100K  :     837.989 micros/op;  11          
readseq      :       0.461 micros/op;                 
readrand100K :      98.598 micros/op;

总之

仅查看 FIO 的原始 IO 性能，我们发现存在相当大的差距：读取和写入带宽似乎都下降了约 30%。然而，在涉及大量交错 IO 和计算的实际使用中，差异基本上消失了。

相关内容