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

Question

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

• 两台服务器挂载相同的 NFS 共享存储，文件数量
• 一台服务器上的客户端应用程序删除了一些文件
• 2 个服务器上的客户端应用程序尝试访问已删除的文件并失败并显示:陈旧的 NFS 文件句柄(没有什么奇怪的，错误是预期的)

(另外，出于性能原因，知道两台服务器上的缓存装载选项都非常高可能也很有用)。

我想了解的是:

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

谢谢。

Answer 1

• Is there reliable method to check, that file is present? In the scenario given above lstat on the file returns success and application fails only after trying to move file.

这就是正常的 NFS 行为。

• How can I manually sync contents of directory on the client with server?

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

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

到目前为止，我对 NFS 的体验是，您无能为力。在关键代码路径中，我只是编码以重试返回 ESTALE 的文件操作。

• Some general advise on how to write reliable file management code in case of NFS?

随心所欲地修改我，但如果您的客户想要可靠性，那么他们不应该使用 NFS。

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

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

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