Summary

  • The IESG-approved NFSv4.2 draft defines a per-file boolean that tells supporting clients to suppress long-lived data caching, but the attribute is advisory and optional to implement.
  • A stored value of true is not proof that a particular open changed mode, that an unstable WRITE was committed, that pNFS metadata became visible or that another application observed the bytes.

A server can now put a precise fact on the wire: this file is unsuitable for ordinary client-side data caching. That is a valuable improvement over asking every application to know which remote files require O_DIRECT-like treatment.

It is not the same as making the cache disappear.

On 17 September, the IESG approved Adding an Uncacheable File Data Attribute to NFSv4.2 and sent it to the RFC Editor queue. Revision 16 defines fattr4_uncacheable_file_data, attribute number 87, as a read-write boolean for regular files and named attributes. In NFS terminology it belongs to the RECOMMENDED attribute class. That class name can mislead outside the protocol: a server is still not required to implement it.

Support attaches to an exported filesystem, not to the server brand as a whole. One export may advertise the attribute while another on the same machine does not. A client can inspect supported_attrs or probe. An unsupported SETATTR fails with NFS4ERR_ATTRNOTSUPP; an unsupported GETATTR simply omits the field. Absence therefore needs interpretation before it becomes a dashboard verdict.

When a client does honor a true value, it must not retain WRITE data merely to merge later operations or improve efficiency. Prompt transmission reduces a particular shared-file hazard: one client can otherwise read a stale block, modify its own byte range and write back over another client's update. The mechanism narrows the time and place in which that stale copy can do damage.

Durability follows a separate chain. The attribute does not choose the NFS stable_how4 value. The draft instead requires that when the application's write call returns successfully, the data be durable on the server. A client may send FILE_SYNC4 or DATA_SYNC4. It may also send UNSTABLE4, but then a COMMIT must finish before control returns to the application. If the server's write verifier changed, the affected WRITEs have to be issued again while the application buffer still exists.

That distinction matters operationally. Retaining bytes briefly so an in-flight unstable WRITE can be committed is not the long-lived cache the attribute is designed to suppress. Conversely, setting the bit does not excuse a missing COMMIT. “Uncacheable” describes a data-cache policy; it is not a synonym for “already durable.”

Read visibility has its own conditions. A client that keeps read data should not reuse it without revalidating the change attribute and file size. A delegation may provide another consistent view. In parallel NFS, the metadata server supplies the attribute while data can travel directly to storage devices. Durability at those devices and visibility through layout metadata are separate events. Where a layout requires LAYOUTCOMMIT, delaying it can leave another client revalidating against earlier metadata even after the bytes themselves are durable.

Time also breaks the tempting one-bit story. If the attribute changes while a file is open, a client may continue the caching behaviour selected at OPEN until that open ends. Attribute-cache expiry and revalidation bound the delay; subsequent OPENs apply the newly observed value. An inventory that reads true today cannot by itself describe every open established yesterday.

The draft is equally careful about authority. A server decides under existing policy whether a requester may set or clear the field. The extension adds no authentication mechanism, changes no access-control rule and creates no security boundary. A client must not use the bit to decide who may read or write. Existing cache-consistency and integrity mechanisms remain responsible for their own jobs.

Revision 16 reports one prototype Hammerspace server and one prototype Linux client, with observed benefits for well-formed I/O. That is evidence that the design can run. It is not evidence of broad implementation, default enablement, interoperability across products or a universal performance gain. The draft itself says the relevant comparison is operational: observe the workload with and without the attribute, on clients that actually honor it.

The useful management model is therefore a receipt chain. Record the specification revision, export support, server policy, value returned to a named client, OPEN epoch, client implementation, WRITE stability mode, verifier and COMMIT, any pNFS LAYOUTCOMMIT, read revalidation and the application-visible result. A green bit is the beginning of that chain, not its conclusion.

Sources