12

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

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

（另外了解一下，出于性能原因，两台服务器上的缓存挂载选项都非常高）。

我想了解的是：

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

谢谢。

4

3 回答 3

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

这是正常的 NFS 行为。

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

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

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

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

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

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

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

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

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

于 2010-07-08T17:08:53.443 回答
5

我在ls -l包含该文件的目录上取得了成功。

于 2014-11-20T20:19:21.803 回答
4

你可以试试''noac''挂载选项

来自 man nfs：

除了防止客户端缓存文件属性外，noac 选项还强制应用程序写入同步，以便对文件的本地更改立即在服务器上可见。这样，其他客户端在检查文件属性时可以快速检测到最近的写入。

使用 noac 选项可以在访问相同文件的 NFS 客户端之间提供更高的缓存一致性，但会导致显着的性能损失。因此，鼓励明智地使用文件锁定。

您可以有两个装载，一个用于需要同步的关键快速变化的数据，另一个用于其他数据。

此外，请查看NFS 锁定及其限制。

至于一般建议：

截断从多个主机同时读取的文件的一种方法是将内容写入临时文件，然后rename将该文件写入最终位置。

在同一个文件系统上，这个操作应该是原子的。

于 2010-07-08T15:34:16.660 回答