我们遇到了一个奇怪的问题，从 NFS 客户端创建/删除文件需要很长时间才能传播到其他客户端。
我们在客户端上的挂载选项有：
defaults,rsize=32768,wsize=32768,intr,noatime,cto
出口有：
*(rw,sync,no_root_squash,no_wdelay)
我们通过在一个客户端上执行以下来验证这一点：
watch -n0.1 stat foofile
然后在另一个客户端上，我们修改了 foofile（或 rm 了它）。修改需要 1 多秒才能传播出去。
cto 和 no_wdelay 是我们最近添加的选项，以查看它们是否能解决问题（但不能）。我们还能查看什么？
答案1
我不会直接回答你的问题。
NFS 客户端无法保证能够快速看到更新。是的，您可以调整参数来控制延迟，但结果将是客户端的缓存更差（因此性能很差）。
通常，当我发现自己需要 NFS 客户端来更快地查看更改时，我会退一步并问自己：“好吧，我在这里真正想要实现什么？”通常我会意识到有一些更高级别的抽象可以让我以非常不同的方式解决相同的问题。例如，有时我意识到我正在尝试将 NFS 文件用作穷人的 RPC 或锁定机制。有更好的方法可以完成这两件事。
NFS 适用于单个客户端访问特定目录。除此之外，如果您遇到问题并打算使用 NFS 修复它，那么您将面临两个问题。
我喜欢 NFS，但是它的使用范围却受到限制。
答案2
这不一定是您的问题，但我有时会发现 NFS 存在一致性问题，即客户端和服务器的时钟并非都严格同步。所有相关系统是否都与 NTP 同步？