![eCryptfs 是否预取和/或缓冲数据?](https://linux22.com/image/1340408/eCryptfs%20%E6%98%AF%E5%90%A6%E9%A2%84%E5%8F%96%E5%92%8C%2F%E6%88%96%E7%BC%93%E5%86%B2%E6%95%B0%E6%8D%AE%EF%BC%9F.png)
我一直在尝试使用 eCryptfs 作为 MySQL 数据的底层文件系统来模拟透明数据加密对于 MySQL。我进行了一些测试来测量 MySQL 读取数据时的解密开销,结果很奇怪。
我准备了一个 7.5 GB 大小的表并运行了全表扫描 (SUM) 查询。我有两种情况 -
- 当底层文件系统为 ext4 且无加密时,多次运行查询的平均时间 -22.5 秒
- 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。
我必须深入研究才能理解这一点。您看到的东西肯定很奇怪。
==消息结束==