ecryptfs的写入性能不佳

我对ecryptfs和dm-crypt进行了一些基准测试，并得到了一些有趣的结果。以下所有操作都是通过Btrfs文件系统完成的，该系统使用dd一个〜700MB的文件向/从ramdisk复制文件，并带有conv=fdatasync强制执行数据同步的选项。每次测试前都会清除磁盘缓存。

No encryption:
 read - 165MB/s
 write - 120MB/s
ecryptfs:
 read - 125MB/s
 write - 15MB/s
dm-crypt:
 read - 150MB/s
 write - 115MB/s
dm-crypt + ecryptfs:
 read - 120MB/s
 write - 15MB/s

现在我知道加密比原始文件系统要慢，但是我没想到ecryptfs会大大降低写入性能。我强迫数据同步的事实是否会使该测试不切实际？还是有什么我可以传递给ecryptfs的选项来加快写入速度？

我在ecryptfs上使用文件名加密，但除此之外，其他所有内容均设置为默认值。

手册页的ddabout fdatasync读取：physically write output file data before finishing，因此它仅以物理方式“一次”写入数据（将其读为“不强制每X个块或字节刷新一次，而在末尾强制刷新一次”）。如果要进行dd测试，这是获得最准确结果的最佳方法。相反，不使用该特定标志将使您的结果不切实际：忽略它可能会浪费加密时间，因为dd它只是在复制数据。

尽管如此，我也认为您的结果有些变化，但是我发现这篇文章显示了几乎相同的内容：ecryptfs非常缓慢。而您的测试（正在复制一个文件）是ecryptfs的最佳情况！

当ecryptfs为每个明文版本写入一个加密文件（带有自定义标头，其中包含元数据）时，拥有很多小文件意味着性能下降更大。

但是，ecryptfs有其优点：您可以立即发送加密的文件而不会丢失加密。备份（假设您正在备份加密的数据）将更快，因为您将仅复制与数据一样大的文件（如果增量文件则复制则更快，因为您仅复制修改的文件）。

另一方面，dm-crypt可能会更快一些，但是您需要发送整个容器（整个文件系统）以保持加密不变。而且备份也将由整个容器组成，在大多数情况下不能执行增量备份。

我曾经（仍然使用）这两种方法（虽然不是同一工具）来保存加密的数据：基于文件的（ecryptfs）更容易通过在线托管服务（例如PC之间的保管箱）保持同步，但是在运行时却很慢进行更改并导致底层文件系统出现了一些问题（它假定它可以写入文件，并且与文件系统限制有关的问题可能会使整个系统崩溃）；我更喜欢块设备加密：我将它们视为简单的分区，因此限制和问题不会严重恶化。唯一的缺点是复制容器，这可能需要更长的时间。