两台机器看到的不一样
NFS 客户端会缓存文件属性与目录项以减少网络往返，这就产生了「A 机器改了文件，B 机器一段时间后才看到」的现象。协议提供的基本保证是关闭后再打开能看到最新内容，但文件处于打开状态时其他客户端的可见性取决于缓存策略与委托机制。遇到一致性疑问时，先确认协议版本与挂载参数，再用禁用缓存的挂载做对比验证，最后才判断是应用逻辑还是缓存行为导致。
基本信息
| 缓存对象 | 文件属性、目录项、部分数据 |
|---|---|
| 控制参数 | 属性与目录项缓存时间，是否禁用缓存 |
| 协议保证 | 关闭后重新打开可见最新内容的语义 |
| v4 差异 | 委托机制会让客户端缓存更积极 |
| 权限要求 | 主机 root/管理员 |
典型使用场景
- 多节点共享目录出现内容或权限不一致的反馈
- 容器与虚拟机共享同一目录时的可见性验证
- 构建与发布流程中文件更新延迟导致的问题
- 调优元数据性能与一致性之间的平衡
- 排查应用缓存与 NFS 缓存叠加造成的误判
验证方法
验证方法
# 1) 确认两端挂载参数是否一致
nfsstat -m
# 2) 临时禁用属性缓存做对照验证（性能代价明显）
mount -t nfs -o vers=4.2,noac server:/export /mnt/verify
# 3) 在两端对比同一文件的时间戳与权限
stat /mnt/data/file
# 4) 观察变更后可见性延迟，判断是否符合预期语义参数与一致性影响
| 参数类别 | 取值方向 | 对可见性的影响 |
|---|---|---|
| 属性缓存时间 | 调大 | 元数据更新可见更慢 |
| 属性缓存时间 | 调小 | 可见更快，元数据请求增多 |
| 目录项缓存 | 保留 | 目录变化可见稍慢 |
| 禁用属性缓存 | 启用 | 接近实时，性能明显下降 |
| 委托机制 | 启用 | 客户端缓存更积极，需理解其回收行为 |
禁用属性缓存是诊断手段而非长期方案：它能快速区分缓存行为与应用问题，但会显著增加元数据往返，长期使用通常得不偿失。
依赖「改动立即被其他客户端看到」设计的应用在共享目录上会出现难以复现的问题；这类需求应在应用层引入明确的同步机制，而不是靠客户端缓存参数实现。