摘要

  • 9 月 26 日的第12版仍是 NFSv4 工作组的有效 Internet-Draft，Datatracker 状态为 I-D Exists，不是已批准的 RFC。
  • 新增的并行 NFS 小节把“客户端不再使用旧缓存”和“元数据服务器已经得知新写入”划成两件事。

一个备份任务遍历共享目录，以文件大小和修改时间决定是否复制。另一台机器刚刚写大了文件，但目录中的名字没有变化。目录自身的 change 属性可以不动；它跟踪的是目录及其条目，而不是被指向文件的每次写入。客户端若仍沿用上次列目录时存下的大小，备份可能误判。草案提出给目录设置一个布尔属性，要求遵守它的客户端每次枚举都发出新的 READDIR，并且不能报告本次 READDIR 返回该条目之前保存的旧属性。

这个基本办法在 9 月 5 日的第11版已有，不能把它包装成第12版首创。新版本更明确地把义务拆成两半：真正重新到服务器取目录，以及报告这次取回的条目属性。仅发一个几乎不请求属性的 READDIR，再拿本地旧值填空，不满足草案意图。客户端可以把需要的属性放入 READDIR 的 attr_request，也可以随后逐项 GETATTR；后者可能让每个条目多一次请求。该属性不禁用文件数据缓存，也不把整个挂载点一概改成“不缓存”。

真正新增的治理边界在第5.2节。并行 NFS 把目录和这个属性交给元数据服务器，数据却可能由单独的存储设备处理。在某些布局中，元数据服务器要等 LAYOUTCOMMIT 才知道写入后新的大小与 time_modify。若 READDIR 比这次提交更早，它自然会返回旧值；客户端如实报告旧值，并没有违反“不用旧缓存”的规则。此时落后的不是客户端记忆，而是对目录提问的服务器尚未掌握存储端的最新事实。

因此，运营方不能把一次“新 READDIR”写成“所有写入都已可见”。草案没有承诺全局一致快照、线性化读取，也没有说每种 pNFS 布局都以相同方式等待 LAYOUTCOMMIT。它只限定了在该条件下客户端能从元数据服务器得到什么。若自动化流程把这项局部保证升级为全链路数据新鲜度承诺，问题就从缓存优化变成了错误的决策依据。

第12版还把开关的权限状态说清楚。服务器可按本地策略拒绝对目录属性的 SETATTR；拒绝应返回 NFS4ERR_ACCESS，或在草案界定的所有权／特权情形下返回 NFS4ERR_PERM，不能返回 NFS4ERR_INVAL。后一个码会让探测支持情况的客户端以为服务器压根不认识该属性。“支持但不给你改”和“尚不支持”需要不同的修复路径，不能在运维面板上合并成一个模糊的失败灯。

文档提到 Hammerspace 服务器和 Linux 客户端原型，但这不等于已有普遍部署、跨实现互通或备份事故的证据。这里报道的是工作组草案对责任边界的澄清，而不是宣布某种已获 IETF 批准的完整一致性方案。

资料