概述

这个问题的结构如下：
我首先给出一些关于我为什么对这个主题感兴趣以及它如何解决我正在处理的问题的背景。然后，我询问有关文件系统缓存的实际独立问题，因此如果您对动机（某些 C++ 项目构建设置）不感兴趣，请跳过第一部分。

最初的问题：链接共享库

我正在寻找一种方法来加快我们项目的构建时间。设置如下： 一个目录（我们称之为workarea）位于 NFS 共享中。它最初只包含源代码和生成文件。然后，构建过程首先在 中创建静态库workarea/lib，然后在 中创建共享库workarea/dll，使用 中的静态库workarea/lib。在共享库的创建过程中，这些不仅被写入，而且还使用例如再次读取nm在链接时验证没有符号丢失。并行使用许多作业（例如 make -j 20 或 make -j 40），构建时间很快就会被链接时间所支配。在这种情况下，链接性能受文件系统性能的限制。例如，并行连接 20 个作业在 NFS 共享中大约需要 35 秒，但在 RAM 驱动器中仅需要 5 秒。请注意，使用 rsync 复制dll回 NFS 共享还需要 6 秒，因此在 RAM 驱动器中工作并随后同步到 NFS 比直接在 NFS 共享中工作要快得多。我正在寻找一种无需在 NFS 共享和 RAM 驱动器之间显式复制/链接文件即可实现快速性能的方法。
注意我们的 NFS 共享已经使用了一个缓存，但是这个缓存只能缓存读访问。
AFAIK，NFS 要求任何 NFS 客户端在 NFS 服务器确认写入完成之前不能确认写入，因此客户端不能使用本地写入缓冲区，并且写入吞吐量（即使在峰值）受网络速度限制。在我们的设置中，这有效地将组合写入吞吐量限制在大约 80MB/s。
然而，读取性能要好得多，因为使用了读取缓存。如果我在 NFS 中链接（创建 的内容dll）workarea/lib并workarea/dll作为到 RAM 驱动器的符号链接，性能仍然不错 …