确保客户端上的文件状态与 NFS 服务器同步

我正在尝试找到正确的方法来处理 NFS 客户端上的过时数据。考虑以下场景：

• 两台服务器挂载具有多个文件的相同 NFS 共享存储
• 1 台服务器上的客户端应用程序删除了一些文件
• 2 个服务器上的客户端应用程序尝试访问已删除的文件并失败并显示：陈旧的 NFS 文件句柄（没什么奇怪的，预计会出现错误）

（此外，了解出于性能原因，两台服务器上的缓存安装选项都相当高可能很有用）。

我想理解的是：

• 是否有可靠的方法来检查该文件是否存在？在上面给出的场景中，文件上的 lstat 返回成功，并且应用程序仅在尝试移动文件后才会失败。
• 如何手动将客户端上的目录内容与服务器同步？
• 关于如何在 NFS 情况下编写可靠的文件管理代码的一些一般建议？

Thanks.

• 是否有可靠的方法来检查该文件是否存在？在上面给出的场景中，文件上的 lstat 返回成功，并且应用程序仅在尝试移动文件后才会失败。

这是正常的 NFS 行为。

• 如何手动将客户端上的目录内容与服务器同步？

这是不可能手动完成的，因为 NFS 假装是一个普通的 POSIX 兼容文件系统。

我曾尝试编写 close()/open() 代码，试图以某种方式减轻 NFS 客户端缓存的影响。就我而言，我需要读取写入其他服务器上的文件的信息。但即使是重新开放的伎俩也几乎为零。我无法将 fdatasync() 添加到写入端，因为这会减慢整个应用程序的速度。

迄今为止，我对 NFS 的经验是您无能为力。在关键代码路径中，我简单地编码以重试返回 ESTALE 的文件操作。

• 关于如何在 NFS 情况下编写可靠的文件管理代码的一些一般建议？

修改我想要的一切，但如果您的客户想要可靠性，那么他们不应该使用 NFS。

例如，如果客户想要可靠性，我的公司就会宣传使用适当的分布式文件系统（我故意省略品牌）。我们的核心软件不保证在 NFS 上运行，并且我们不支持此类配置。但在我们的例子中，我们确实需要保证一旦数据写入 FS，它们就可以在所有其他节点上访问。

NFS 可以实现一致性，但会以性能为代价，使得 NFS 几乎无法使用。 （检查其挂载选项。） NFS 疯狂地进行缓存，以隐藏它是服务器文件系统的事实。为了使所有操作保持一致，NFS 客户端必须绕过本地缓存，同步访问 NFS 服务器来执行每个小操作。那永远不会很快。

但由于我们在这里讨论的是 Linux，因此可以建议该软件的客户评估可用的集群文件系统。例如。 RedHat现已正式支持GFS http://en.wikipedia.org/wiki/Global_File_System。我听说有人使用 CodaFS，但没有确切的信息。