![使用FIO](https://linux22.com/image/230622/%E4%BD%BF%E7%94%A8FIO.png)
关于在 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 和计算的实际使用中,差异基本上消失了。