☰

eCryptfs 是否预取和/或缓冲数据？

tag-icon • tag-icon filesystems encryption mysql ecryptfs
eCryptfs 是否预取和/或缓冲数据？

我一直在尝试使用 eCryptfs 作为 MySQL 数据的底层文件系统来模拟透明数据加密对于 MySQL。我进行了一些测试来测量 MySQL 读取数据时的解密开销，结果很奇怪。

我准备了一个 7.5 GB 大小的表并运行了全表扫描 (SUM) 查询。我有两种情况 -

  1. 当底层文件系统为 ext4 且无加密时，多次运行查询的平均时间 -22.5 秒
  2. eCryptfs 安装在 ext4 之上 -
    • 首次创建表时，查询的平均运行时间为21 秒（因为它比未加密的要小，是否涉及一些预取？）
    • 清除 MySQL 缓冲区并重新运行查询，现在的平均运行时间为9.6 秒（由于 eCryptfs 缓冲？）
    • 如果我卸载目录并重新挂载但不重新创建数据，则平均时间会达到17 秒。这又是一个谜。eCryptfs 在第一次解密时是否存储了一些未加密的元信息？

我多次运行这些测试（每次都清除 MySQL 缓冲区），并得到了一致的结果。有人可以解释或指出一个资源来解释这种行为吗？是否可以禁用此功能（用于测试）？

答案1

我在 eCryptfs 的邮件列表中问了同样的问题。这是主题 -

http://comments.gmane.org/gmane.comp.file-systems.ecryptfs.general/294

其中一位主要贡献者 Tyler Hicks 回复了该查询，并复制到此处（以防链接失效）

==开始消息==

乍一看，你的测试结果对我来说没有任何意义。

在大多数内核版本中，eCryptfs 使用直写缓存。有几个内核版本实现了回写缓存​​，但它导致了一些问题，因此该补丁已被恢复。

对于您正在执行的 SUM 查询，我预计它都是读取的，因此写回或写通应该不会有太大影响。在较低的文件系统中会有一层加密页面的缓存，然后在 eCryptfs 级别会有另一层解密页面的缓存，因此这与您仅使用普通 ext4 时肯定不同。

您谈到了在测试之间清除 MySQL 缓冲区和 eCryptfs 页面缓存（通过卸载并重新安装 eCryptfs）。仍有下层文件系统页面缓存未被清除。也许这与之有关，但我怀疑这不是全部原因。

您是否使用了 innodb_flush_method=O_DIRECT？eCryptfs 不实现直接 I/O，因此我不确定 MySQL 如何在 eCryptfs 和 ext4 上处理该问题，而 ext4 确实可以实现直接 I/O。

我必须深入研究才能理解这一点。您看到的东西肯定很奇怪。

==消息结束==

相关内容