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

beg*_*ray 11 c linux nfs

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

  • 两台服务器使用多个文件挂载相同的NFS共享存储
  • 1服务器上的客户端应用程序删除一些文件
  • 2服务器上的客户端应用程序尝试访问已删除的文件,但失败的是:过时的NFS文件句柄(没什么奇怪的,预计会出错)

(另外,可能有用的是要知道,出于性能原因,两个服务器上的缓存安装选项都相当高).

我想要了解的是:

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

谢谢.

Dum*_*001 13

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

这就是正常的NFS行为.

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

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

我试过一次代码close()/ open(),试图以某种方式减轻NFS客户端缓存的影响.在我的情况下,我需要读取写在其他服务器上的文件的信息.但即使是重新开放的技巧也几乎没有效果.而且我无法在写入方面添加fdatasync(),因为这会减慢整个应用程序的速度.

我迄今为止使用NFS的经验是你无能为力.在关键代码路径中,我只是编码重试返回ESTALE的文件操作.

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

根据您的需要修改我,但如果您的客户需要可靠性,那么他们就不应该使用NFS.

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

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

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


vc2*_*273 7

我已经成功地对ls -l包含该文件的目录进行了操作。


mie*_*war 5

您可以尝试“noac”安装选项

来自 man nfs:

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

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

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

另外,请研究NFS 锁定及其限制

至于一般建议:

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

在同一文件系统上,此操作应该是原子的。