Summary

  • Revision 12 of an active NFSv4 Working Group Internet-Draft adds an explicit parallel-NFS limit to its proposed per-directory metadata-caching control.
  • An honoring client can discard its old directory-entry attributes and still receive values that predate a write the metadata server has not learned about.

Imagine a backup process deciding whether to copy a file from the size and modification time in a directory listing. Another client has written to that file. The directory's own change attribute need not move, because the name and entry have not changed. A local cache can therefore yield an old size without warning. The proposal called Adding an Uncacheable Dirent Metadata Attribute to NFSv4.2 tackles that first problem: a server marks a directory, and a client that honors the attribute uses a new READDIR for each enumeration rather than recycling an earlier listing. It must not report an entry's metadata from a value held before the READDIR that most recently returned the entry.

That mechanism was already in the 5 September revision. The 26 September revision makes its two-part obligation more explicit. A client cannot merely send a token READDIR with a minimal attribute request and then present size or timestamps from its old cache. It should request the attributes it intends to report in READDIR, or obtain them afterward. The latter may mean a GETATTR for every entry. The proposal is therefore about a particular operational trade-off: additional server work and traffic in exchange for avoiding a known class of client-side stale metadata.

It does not forbid caching file contents or turn every file under the mount into an uncached object.

The sharper news is the new §5.2 on parallel NFS. Under pNFS, a metadata server supplies the directory and the attribute; a separate storage device can serve the data. For a layout in which the metadata server learns the file's changed size and modification time only at LAYOUTCOMMIT, a READDIR that runs first returns the earlier values. The honoring client then reports precisely those earlier values. It has obeyed the new rule. No cache shortcut caused the result. The metadata server simply did not yet possess the newer fact.

This distinction prevents the word “fresh” from doing too much work. Fresh relative to a client's previous enumeration is not the same as current relative to all writes on all storage devices. Nor does the draft promise linearizable directory scans, a global snapshot, or a particular latency from a data write to metadata visibility. Its pNFS example is expressly conditional on the layout's commit behavior, not a claim that every pNFS write waits for the same event.

Revision 12 also tightens the administrative edge. The attribute is a per-directory, read-write boolean, but a server may refuse a request to set or clear it under local policy. The draft now says a policy refusal uses NFS4ERR_ACCESS, or NFS4ERR_PERM for the specified owner/privilege case, and not NFS4ERR_INVAL. The latter would lead a support probe to conclude that the server does not know the attribute. A denied request and an unsupported mechanism are different observations. Neither should be silently reported to an operator as “cache protection enabled.”

The Datatracker still lists this as an active Working Group Internet-Draft at “I-D Exists,” not an RFC. The implementation section describes a prototype Hammerspace server and prototype Linux client; it is not a field survey or production assurance. The proposal is precise enough to evaluate, but a deployment claim needs evidence of server support, setter authority, honoring clients, and the layout's metadata update path.

Sources