摘要

  • NFSv4 工作组 9 月 29 日发布的 ACL 草案第 06 版，将拟议的可选属性 ACL_Choice 从编号 87 调到 89。另两份仍属草案的文件分别把 87 用于文件数据不可缓存标记、88 用于目录条目元数据不可缓存标记。
  • 同一修订把四种拟议 ACL 大小错误码由 20000–20003 改为 10095–10098，并新增限制：服务器或当前访问的文件系统不支持 AclChoice 时，不得返回这些错误。该段仍明确标为有待达成共识。

看协议抓包时，编号往往最先映入眼帘；它也最容易被误读成能力证明。9 月 14 日的《ACLs within the NFSv4 Protocols》第 05 版拟把 ACL_Choice 放在 87。十五天后的第 06 版在属性表和 XDR 常量中都改为 89。变更日志说得很具体：给即将推进的不可缓存文件与目录属性让位。对应草案目前以 87 表示 uncacheable_file_data，以 88 表示 uncacheable_dirent_metadata。

这里没有证据表明生产系统已经因编号冲突发生事故。被挪动的 ACL_Choice 是 NFSv4.1 修订方案里的可选属性，目的在于向客户端描述 ACL 行为选择；另两个标记讨论缓存。三者解决不同问题，当前也都不是已批准 RFC 中不可更改的最终分配。对基于旧草案做过原型的团队，实际工作是标明测试针对哪一版，再核对常量和解码结果；不能仅凭草案改动推断某家产品曾使用旧编号。

错误码变化比编号表更能说明能力边界。草案用四个名称区分 ACL 太大而无法存放或取回的不同情况：NFS4ERR_ACLST_POORFIT、NFS4ERR_ACLST_NOFIT、NFS4ERR_ACLST_TOOBIG 和 NFS4ERR_ACLFT_TOOBIG。第 05 版把它们放在 20000 至 20003；第 06 版改为 10095 至 10098。新增条款还规定：没有 AclChoice 的服务器不能返回它们；即使服务器整体实现了该属性，当前访问的文件系统不支持时也不能返回。服务端的总体描述和某个导出卷的能力，不是同一份证据。

设想测试客户端访问同一服务器的两个导出目录，一个底层文件系统支持拟议属性，另一个不支持。客户端认识数字 10095，最多证明自己的解码表包含这个名称；它不能因此断言第二个导出卷也提供相同的 ACL 语义。要判断一次响应，至少还需知道草案版本、访问目标和属性支持状况。这是用来界定验证步骤的假设场景，并非对现实故障的报道。

Datatracker 目前将第 06 版列为 NFSv4 工作组的有效 Internet-Draft，状态仍是 I-D Exists。首页写明只有“获批后”才会更新 RFC 7530 与 RFC 8881。草案说工作正在为未来的工作组最终征求意见做准备，错误一节也保留“Consensus Needed”标记。因而，新增的 MUST NOT 应理解为仍待讨论的规范草案用语，不是已经生效的既有标准义务。

资料来源