摘要

  • IESG 已批准的 NFSv4.2 草案定义了逐文件布尔属性，要求支持它的客户端限制长期数据缓存；但服务器并非必须实现，属性本身也只是建议信号。
  • 读到 true，不等于既有 OPEN 已改变模式、非稳定 WRITE 已完成 COMMIT、pNFS 元数据已经可见，或另一应用已经看到新字节。

一台服务器终于可以通过协议明确表达：这个文件不适合按普通方式放进客户端数据缓存。对高性能计算和多个客户端并行修改同一文件的工作负载而言，这比要求每个应用都单独理解并采用类似 O_DIRECT 的本地接口更统一。

但服务器写下这个事实，不会自动清空客户端的缓存。

9 月 17 日，IESG 批准了 Adding an Uncacheable File Data Attribute to NFSv4.2，并把文件送入 RFC Editor 队列。第 16 版把 fattr4_uncacheable_file_data 定义为属性 87：逐文件、布尔型、可读写，适用于普通文件与命名属性。它在 NFS 术语中属于 RECOMMENDED 属性类别；这里的名称并不表示所有服务器都必须支持。

支持范围落在具体导出文件系统，而不是整台服务器。相同服务器上的两个导出可以给出不同答案。客户端需要查看 supported_attrs 或主动探测。不支持该属性的 SETATTR 返回 NFS4ERR_ATTRNOTSUPP；不支持它的 GETATTR 则只是省略字段。因此，“没有看到”在进入告警系统前还需要解释。

当客户端确实遵守真值时，它不得为了合并多次操作或提高效率而推迟发送 WRITE。规则瞄准的是一个具体风险：多个客户端修改同一数据块内互不重叠的字节区间时，其中一方可能基于旧副本做读改写，再覆盖另一方的新数据。尽快发送能够缩短这种写洞形成的窗口。

持久性却有另一条证据链。属性不指定 stable_how4。草案单独规定：应用的写调用成功返回时，数据必须已在服务器上持久化。客户端可以使用 FILE_SYNC4 或 DATA_SYNC4；也可以发送 UNSTABLE4，但必须在返回应用前完成 COMMIT。如果写校验器发生变化，还要趁应用缓冲区仍存在时重发受影响的 WRITE。

为完成这次非稳定写与提交而短暂保留字节，不属于属性要压制的长期缓存。反过来，设置布尔值也不能弥补缺失的 COMMIT。“不可缓存”描述缓存政策，不是“已经落稳”的回执。

读取可见性还要再走一步。保留读取数据的客户端，不应在重新校验 change 属性和文件大小之前重复使用它。某些场景可以由 delegation 提供另一种一致视图。在 pNFS 中，元数据服务器给出属性，数据却可能直达存储设备。字节在设备上持久化，与布局元数据让其他客户端看见它，是两件事。需要 LAYOUTCOMMIT 时，延迟提交会让别的客户端继续根据旧元数据进行校验。

时间也会拆穿“一位即全局状态”的错觉。文件已经打开后再修改属性，客户端可以在这次 OPEN 的整个生命周期里继续沿用原先选定的缓存行为。属性缓存到期、重新校验和后续 OPEN 会限制延迟，但今天读到的 true 不能自动描述昨天建立的所有打开实例。

这个字段也没有借到安全权力。谁能设置或清除它，仍由服务器既有政策与授权决定。草案没有增加认证机制，没有修改访问控制，也没有创建安全边界。NFSv4.2 原有的一致性与完整性机制仍各自负责。

第 16 版披露了 Hammerspace 服务器原型和 Linux 客户端原型，并报告对规范 I/O 的若干收益。这能证明设计有运行代码，不证明广泛部署、默认启用、跨产品互操作或所有工作负载都会提速。草案本身要求在实际运行中比较：客户端是否真正遵守，设置前后又发生了什么。

因此，可靠台账不能只存一个布尔值。它要连接规范版本、导出支持、服务器政策、具名客户端看到的值、OPEN 时点、客户端实现与版本、WRITE 稳定模式、校验器和 COMMIT、必要的 LAYOUTCOMMIT、读取校验，以及应用最终看见的结果。这个位是证据链的起点，不是终点。

来源