摘要

  • fattr4_uncacheable_file_data 记录服务器希望如何处理某个文件，不记录某个客户端此刻的内部缓存状态。
  • 对已打开文件，属性变化与客户端采用新行为之间可以存在时间差；读取与写入还各有自己的协议证据。
  • 运维记录应把服务器策略与客户端观察分开，再以文件、打开纪元和具体操作关联，不能用一个绿色状态替代全过程。

一个布尔值跨不过状态边界

网络文件系统的缓存不是旁门左道，而是性能模型的一部分。客户端把数据留在靠近应用的位置，再依靠变更属性、打开状态、锁和委托判断能否继续使用。问题在于，并非所有文件都适合这笔交易。有些负载更在意可预期的可见性或写入时点，服务器管理员因此需要一种标准方式，告诉客户端不要照常缓存文件数据。

draft-ietf-nfsv4-uncacheable-files-13 提议的属性填补了这一表达空白。但策略一旦进入资产面板，就容易被改写成结果：“值为真，所以客户端已经不缓存。”这个结论超出了服务器能够观察的范围。客户端是否实现该属性、目标导出文件系统是否支持它、客户端何时读取到当前值，以及本地实现怎样兑现建议，都是彼此分离的事件。

最能暴露差距的是已经打开的文件。草案允许客户端在服务器修改属性后，暂时沿用此次打开原有的缓存行为，不要求它立刻重构一个活跃会话。客户端可以在常规 GETATTR 或重验证中发现新值，并把新行为用于后续操作。因此，服务器在 10:00 写入的真值与客户端在 10:07 首次采用它可以同时成立。把两者压成一个“生效时间”，只是让仪表板更整齐，却丢掉了真正需要解释的七分钟。

先把支持、取值和授权拆开

新属性编号为 87，可读可写，在 NFS 属性表中归入 RECOMMENDED。这里的“推荐”是属性分类，并不构成所有 NFSv4.2 服务器必须实现的独立要求。更重要的是，支持能力属于导出的文件系统。同一台服务器上的两个文件系统可能给出不同答案。以产品名称或另一个挂载点的测试结果推断当前导出能力，证据层级并不够。

对象类型也会改变读数的含义。该属性针对普通文件和具名属性；在其他对象类型上读取会返回假，设置则会失败。于是，“假”至少可能表示三件不同的事：这个文件允许普通缓存、这个对象不适用、或者当前文件系统根本未提供预期能力。审计数据如果不同时保留对象类型、支持位图和属性值，就无法区分它们。

属性值从何而来也同样重要。服务器可以允许修改，也可以按本地策略始终拒绝；它还可能通过挂载规则，让新建文件自动获得真值。正常授权机制仍然适用。一条只有真假两栏的历史，无法说明谁有权决定、哪条规则产生结果，或一次被拒的设置请求是否让旧值继续有效。

写入的关键不是“内存为零”

客户端尊重该属性时，不得只为合并请求或提高效率而延迟 WRITE。更严格的约束出现在应用看到成功的时刻：写调用一旦成功返回，数据必须已经在服务器上具备持久性。

协议允许不同路径达到这个结果。客户端可以请求稳定写，也可以先发送不稳定写，再在向应用返回之前完成 COMMIT。如果服务器给出的写验证器发生变化，受影响的数据必须从仍可用的缓冲中重新发送。为了完成正在进行的写操作而暂时保留数据，不被草案视为要禁止的缓存。

这正说明“客户端缓存是否为空”不是合适的审计目标。一个正确实现可能仍在短时间内持有字节，以便处理验证器变化。真正需要留存的是因果顺序：请求和返回的稳定模式、COMMIT 结果、前后验证器、是否重发，以及应用调用被允许成功的时间。遇到断电或服务器切换时，只有这条链能帮助判断某次已经确认的写入是否满足了承诺。

读取新鲜度来自重验证证据

在读取侧，草案没有要求每次都表演一次彻底清空。它要求客户端不要在未经重验证的情况下重用缓存数据。最低限度是检查 NFS 变更属性和文件大小；实现可以再检查更多信息。

这个要求延续了 NFSv4.1 的一致性逻辑。缓存有效性不只依赖本地时钟猜测，而要与变更属性、打开、共享保留、锁和委托结合。若客户端持有能够保证一致视图的委托，即使不可缓存属性为真，保留读取缓存仍可能合理。治理问题不该问“内存页是否存在”，而该问“客户端凭什么认为这次操作可以使用它”。

一张可检验的读取凭证可以保存前后变更值、比较过的文件大小、重验证时点，以及提供替代一致性保证的委托或锁。随后记录采取的动作：继续使用、失效、重新获取或失败。这样的记录允许事后反驳和复算；一句“已遵从策略”不具备同样价值。

两张记录，各自回答一个问题

服务器侧记录可以很窄：服务器与导出文件系统身份、属性 87 的支持情况、文件身份、当前值、策略来源、授权主体和观察时间。它回答的是：服务器在这个时点为这个文件发布了什么处理意图？

客户端侧凭证则要标明实现与版本、挂载、文件句柄和打开纪元；它记录客户端何时看见该值、文件当时是否早已打开，以及哪一次后续操作首先采用新行为。读取操作附上变更属性、大小、委托和缓存动作；写入操作附上稳定模式、COMMIT、验证器连续性、重发和应用返回时间。它回答的是：这台客户端怎样处置收到的意图？

两张记录应通过文件和操作身份关联，却不能互相覆盖。服务器修改与客户端观察若相差数分钟，两个时间都是事实。单一“有效时间”会消除传播延迟，使旧版本客户端、长期打开句柄和实现差异看起来像同一状态。

自愿采用应呈现为分布

该方案依据 RFC 8178 规定的扩展机制为 NFSv4.2 增加能力，不需要否定 RFC 7862 的基础规范。它是可选能力，客户端也可以在约束之内选择具体实现。这不是标准化缺陷，而是正常的协议演进。运维者因此必须展示能力分布，而不能把最新语义假定为全网既成事实。

草案的实现状态章节记录了 Hammerspace 服务器原型和 Linux 客户端原型。后者对配置挂载点下的文件采取类似直接 I/O 的做法，并在合适负载上报告了性能、内存和 CPU 收益。这些结果证明方案可以被实现，却不保证所有客户端会采用相同设计，也不保证每类负载都得到同样收益。“类似直接 I/O”不能被悄悄改成“就是直接 I/O”，一项原型也不能替代异构环境的测量。

更诚实的上线视图至少包含五类：不支持、支持但未设置、已设置但客户端尚未观察、已被客户端用于新操作、以及已有具体操作凭证。这样的分布能显示采用前沿，也能分清升级缺口与观测缺口。一个汇总绿灯做不到。

安全边界不能借位

草案明确说明，新属性没有增加授权或访问控制，也不得被用来作安全决策。对属性的修改可能影响其他客户端的性能和数据可见性体验，因此修改者身份值得审计。但属性值并不是完整性封印、保密控制，也不保证旧数据在任何地方绝对不存在。

产品说明和事故报告应守住这条边界。管理员可以证明服务器请求限制缓存；也可以进一步证明某台受测客户端重验证了一次读取，或在返回成功前让一次写入持久化。不能只凭前一句自动得到后一句，更不能把两者合成“形成了安全隔离”。

新属性真正带来的进步更小，也更实用：服务器终于可以用标准字段表达一项偏好。客户端观察凭证再把这项偏好转成可测试的行为。两者分开保存，运维者才能知道它在哪儿生效、在哪儿没有生效，以及为什么。

来源