Summary

  • The proposed NFSv4.2 attribute expresses a server-side preference for limiting file-data caching; it does not certify that a named client has emptied its cache or changed an already-open file's behaviour.
  • A defensible operational claim needs a second, client-side receipt covering observation time, open epoch, read revalidation, delegation context, stable writes, COMMIT and verifier continuity.
  • The distinction matters because the attribute is optional, advisory, filesystem-specific and explicitly not a security boundary.

A policy bit meets a stateful client

The attraction of fattr4_uncacheable_file_data is immediate. Some files are poor candidates for the performance bargain that network filesystems normally make: keep data close to the application, then use protocol rules to decide when it remains safe to reuse. A server or administrator knows that a workload values predictable visibility more than the usual caching gain. A per-file boolean gives that judgment a protocol address.

The temptation is to read the boolean as a result. “True” can easily become shorthand for “the clients are not caching this file.” The current draft does not support that leap. The value lives at the server. A client must support the attribute, obtain it for the relevant filesystem and file, observe its current value, and translate the advice into its own read and write behaviour. Those events do not occur at the same instant.

The gap is widest for a file already in use. The draft allows a client that has the file open to continue its existing cache treatment after the server-side value changes. The client can discover the new value through its ordinary attribute checks and apply new behaviour to subsequent operations. This is a sensible compatibility choice. It also means that a snapshot of the server attribute cannot answer the operational question people will actually ask after an incident: what did client C believe when operation O completed?

Support is a property of the exported filesystem

Attribute 87 is read-write and described as RECOMMENDED in the NFS attribute table. In this context, that label classifies an attribute; it does not compel every NFSv4.2 implementation to offer it. Support can differ among exported filesystems served by the same machine. A client therefore has to inspect the supported-attribute information for the filesystem it is using, not infer capability from a server product name or a successful test against another export.

The value also has a deliberately narrow object domain. It is meaningful for regular files and named attributes. A read against another object type returns false, while an attempt to set it on an inappropriate type fails. That false value is not equivalent to a positive statement that the filesystem supports the mechanism and policy has selected ordinary caching. Type, support and value must remain separate fields in evidence.

Server policy further qualifies the result. An implementation can permit changes, refuse them, or derive the value through an administrative rule such as a mount option for newly created files. Normal authorization applies. An audit record that stores only true or false loses who was allowed to decide, which policy produced the value, and whether a rejected change left the preceding value in force.

Write-behind changes the meaning of success

On the write path, limiting the cache is not merely a request to reduce memory use. A client honoring the attribute must not delay WRITE operations just to combine them or improve efficiency. More importantly, when an application write returns success, the data must be durable on the server.

There is more than one valid route to that outcome. A client can request a stable write. It can also send an unstable write and issue COMMIT before returning success to the application. If the server's write verifier changes, the client has to resend the affected data from a buffer it still possesses. The draft does not classify temporary retention needed to complete an in-flight write as prohibited caching.

This sequence is why “cache empty” is the wrong audit target. The client may legitimately retain bytes while establishing durability. What an operator needs is a causal record: the stable mode requested and returned, the COMMIT result, the verifier before and after, any replay, and the time the application call was allowed to succeed. Without that sequence, the server attribute says nothing about whether a particular acknowledged write survived the failure mode under investigation.

Fresh reads require evidence of revalidation

On the read path, the draft does not require a theatrical purge after every access. It tells clients to avoid reusing cached file data without revalidating it. At minimum, checking the NFS change attribute and the file size satisfies that expectation. A client may check more.

That rule inherits an important idea from the established NFSv4.1 model. Cache validity is not determined by wall-clock intuition alone. The change attribute is part of the protocol evidence, and caching is coordinated with opens, share reservations, locks and delegations. A delegation may give a client a consistent view that makes read caching appropriate even when the new attribute is true. The governance question is therefore not whether a memory page existed. It is whether the client had a valid protocol basis to use it for the operation at issue.

A useful read receipt would capture the previous and observed change values, the file sizes, the point at which revalidation occurred, and any delegation or lock that supplied an alternative consistency guarantee. It would also record the action taken—reuse, invalidate, refetch or fail. Those details make the evidence falsifiable. A generic compliance flag does not.

An observation receipt beside the policy record

The smallest useful evidence model has two linked parts. The server record identifies the server and exported filesystem, confirms support for attribute 87, stores the file identity and value, names the policy source and authorizer, and timestamps the observation. It answers: what treatment did this server advertise for this file at this point?

The client receipt identifies the client implementation and version, mount, file handle and open epoch. It records when the client learned the value, whether the file was already open, and which subsequent operation first used the new treatment. For reads it adds change, size, delegation context and the cache action. For writes it adds stability mode, COMMIT, verifier continuity, replay and application-return time. It answers: what did this client do with that advice?

Neither record should overwrite the other. If the server value changes at 10:00 and an already-open client observes it at 10:07, both times are true. Collapsing them into one “effective” timestamp produces a clean dashboard at the cost of the event that matters.

Optional adoption is not a defect to conceal

The proposal extends NFSv4.2 through the mechanism defined for adding protocol features without invalidating the base specification. It is optional, and client behaviour remains flexible within the stated invariants. That is normal protocol evolution. It means fleet reporting must show capability distribution rather than present the newest semantic as universal.

The draft's implementation-status section describes a Hammerspace server prototype and a Linux client using behaviour similar to direct I/O for files under a configured mount point. It reports performance and resource benefits for suitable workloads. This is valuable implementation evidence, but not a promise that all clients will use the same design or obtain the same result. “Similar to direct I/O” should not be silently upgraded to “is direct I/O,” and one prototype should not become the expected baseline for a heterogeneous estate.

A practical rollout report would therefore separate unsupported, supported but unset, set but not yet observed, observed for new operations, and verified through operation receipts. That distribution reveals the adoption frontier. A single green percentage hides it.

The attribute cannot carry a security claim

The draft is explicit that the attribute introduces no new authorization or access-control mechanism and must not be used for access decisions. It can influence other clients' performance and visibility behaviour, so the authority to set it still matters. But the value is not an integrity seal, a confidentiality control or proof that stale data is impossible.

This boundary should survive product copy and incident reporting. An administrator may correctly say that policy requested limited caching. They may correctly say that a measured client revalidated a read or made a write durable before returning. They should not combine those statements into the larger claim that the attribute created a security boundary.

The useful achievement here is more modest and more operational: the protocol can carry a server's preference in a standardized field. With a separate observation receipt, operators can then test where that preference became client behaviour, where it did not, and why.

Sources