我试图find正确的方式来处理在NFS客户端上的陈旧的数据。 考虑以下情况：
（由于性能的原因，两台服务器上的高速caching挂载选项相当高）也许是有用的。
我想了解的是：
谢谢。
- 有没有可靠的方法来检查，该文件存在？ 在上面给出的情况下，lstat文件返回成功，应用程序只有在尝试移动文件后才失败。
这是正常的NFS行为。
- 如何手动同步客户端上的目录的内容与服务器？
这是不可能的手动，因为NFS假装是一个正常的POSIX兼容的文件系统。
我试过一次编码close（）/ open（），试图以某种方式减轻NFS客户端缓存的影响。 在我的情况下，我需要读取写入其他服务器上的文件的信息。 但即使重新开放的伎俩也接近零效应。 而且我不能将fdatasync（）添加到写入端，因为这会降低整个应用程序的速度。
我迄今使用NFS的经验是没有什么可以做的。 在关键代码路径中，我简单地编码以重试返回ESTALE的文件操作。
- 一些一般的建议如何编写可靠的文件管理代码在NFS的情况下？
把所有你想要的东西都化为乌有，但如果你的客户想要可靠性，那么他们就不应该使用NFS。
如果客户需要可靠性，我公司举例来说推广使用适当的分布式文件系统（我故意省略品牌）。 我们的核心软件不能保证在NFS上运行，我们不支持这种配置。 但在我们的情况下，我们确实需要这样的保证：一旦数据写入FS，它们就可以在所有其他节点上访问。
NFS的一致性可以实现，但是以牺牲性能为代价，使得NFS几乎不可用。 （检查它的挂载选项。）NFS被疯狂地缓存以隐藏它是服务器文件系统的事实。 为了使所有的操作一致，NFS客户端将不得不同步到NFS服务器进行每一个小操作，绕过本地缓存。 而那永远不会很快。
但是由于我们在这里正在讨论Linux，所以可以建议客户使用该软件来评估可用的群集文件系统。 例如RedHat现在正式支持GFS 。 我听说过使用CodaFS的人，但没有很好的信息。
您可以尝试“noac”安装选项
从man nfs：
除了防止客户端缓存文件属性外，noac选项还会强制应用程序写入同步，以便立即在服务器上显示对文件的本地更改。 这样，其他客户端在检查文件的属性时可以快速检测到最近的写入。
使用noac选项可以在访问相同文件的NFS客户端之间提供更高的缓存一致性，但是会提高性能。 因此，鼓励谨慎使用文件锁定。
你可以有两个坐骑，一个用于关键的快速变化的数据，你需要同步，另一个用于其他数据。
另外，看看NFS锁定和它的限制 。
至于一般意见：
截断从多个主机并发读取的文件的一种方法是将内容写入临时文件，然后将该文件rename为最终位置。
在同一个文件系统上，这个操作应该是原子的。
我已经在包含该文件的目录上做了ls -l成功。