Summary

  • LAYOUT_WCC lets a pNFS client send data-file attributes learned from NFSv3 operations to the metadata server, which may then avoid a separate GETATTR probe.
  • The client may omit the observations and the metadata server may ignore them or verify directly; a successful operation contains no per-attribute acceptance receipt.
  • Attribute reporting is distinct from stable storage, mirror agreement, access control and the bytes an application eventually reads.

Imagine a metadata request arriving just after a client has extended a large file through a data server. The client already holds the data server's post-operation attributes. The metadata server can either ask that data server again or receive the observations from the client that performed the I/O. RFC 9766 standardizes the second path.

The apparent economy is simple: avoid a round trip. The governance consequence is subtler: who is allowed to turn a report into the file's public metadata state? The standard keeps that decision with the metadata server. The client becomes a useful witness, not the final authority.

Parallel I/O created a visibility gap

Parallel NFS separates two surfaces of one file. The metadata server manages namespace and metadata, issues and recalls layouts, and can serve I/O itself. A layout can also direct a client to data servers that hold file contents. The flexible file layout permits those data servers to speak existing NFS versions, including NFSv3.

That separation removes the metadata server from some data operations. A client holding a read/write layout can write directly to a data server. With NFSv3 on that path, there is no universal back-channel by which the data server announces the change to the metadata server. The file grew in one place while the service responsible for answering a later metadata query may not yet know.

The metadata server can recover the missing view by issuing NFSv3 GETATTR. It can compare modification, change and access times and retrieve other current attributes. But every probe is another request, and a large population of metadata queries can turn verification into load on the data tier. A WRITE followed by GETATTR also costs two round trips where a compound NFSv4 operation could carry both in one.

RFC 9766 adds NFSv4.2 operation 77, LAYOUT_WCC, to exploit information already present at the client. NFSv3 READ, WRITE and COMMIT responses can carry Weak Cache Consistency data. The client maps those values into NFSv4 attributes and reports them to the metadata server.

Weak is a property, not an apology

The name matters. RFC 1813 defines WCC around selected pre-operation attributes and post-operation attributes. A client can compare them to decide whether some other operation may have changed the object and whether cached data should be invalidated. It is better evidence than a lone after-image.

It is not strict consistency. RFC 1813 says the pre-state, modifying operation and post-state need atomic treatment for the strongest WCC result. If another actor can modify the object inside that observation window, information is lost. Even a correct WCC result describes particular attributes around a particular operation; it is not a lock on every later writer.

RFC 9766 preserves that weakness rather than hiding it. The metadata server may use the client's report to avoid a probe. It may also issue GETATTR anyway when policy, age, conflict or consequence demands a stronger view. The optimization never removes the verifier's local choice.

The asymmetry is explicit. A client can ignore the WCC information it received. A metadata server can ignore attributes in LAYOUT_WCC. Because the client has no remedy when the server declines the data, the result does not include a bitmap showing which attributes were accepted. A protocol-level success therefore says the operation was processed without the returned error; it does not say every reported field became authoritative metadata.

Eight fields travel together

For the flexible file layout payload, the report maps eight NFSv3 attributes into NFSv4.2 form: size, space_used, mode, owner, owner_group, time_access, time_modify and time_metadata. The uid and gid become string-valued owner fields.

This set combines capacity, time and authority-adjacent information. That makes provenance essential. A change in size can indicate a write. A change in access time can indicate a read. An owner or mode mismatch can explain an access error. None of those observations alone establishes the cause.

RFC 9766 suggests moments when the report can save work. The client may send it before asking the metadata server for size, used space, the change attribute or relevant times. It may attach observations when reporting NFS4ERR_ACCESS, allowing the metadata server to compare expected and actual uid/gid state. It may send the report when refreshing access and modification times proxied under an appropriate delegation.

Those examples are decision points, not automatic repair instructions. On an ownership mismatch, the metadata server might repair permissions or revise its cached expectation. Which direction is correct depends on the authoritative configuration and current layout state. Automating SETATTR from the mere existence of a mismatch would promote a diagnostic receipt into write authority.

The identity is not an array position

A report first identifies a layout with the current filehandle and lowa_stateid; lowa_type says how to interpret its opaque payload. Within a flexible file layout, the report can describe mirrors and the data servers beneath them.

The arrays resemble the layout structure, but position is deliberately insufficient. A client with three mirrors might include all three and give the unchanged one an empty attribute mask. It might instead send only the two that changed. The metadata server must identify a data file through the combination of device ID, stateid and data-file handle. All three are required because a layout can place multiple data files on one storage device.

This is a small example of a larger evidence rule: adjacency is not identity. “The second item” is only meaningful while every producer preserves the same complete list. A durable receipt names the object through fields designed to survive omission and reordering.

Errors make the boundary still clearer. When LAYOUT_WCC fails with an allowed error, the metadata server can ignore the complete operation or, where the layout-specific payload permits, apply only part. A useful audit record must therefore say which identified data file and which attributes were accepted. An RPC status alone cannot reconstruct a partial decision.

Reporting is not committing

File size and modification time are tempting proxies for data safety. They are not a stable-storage receipt. The flexible file layout separately requires the client to make unstable writes stable with COMMIT before LAYOUTCOMMIT when the write did not return FILE_SYNC. LAYOUT_WCC does not collapse that sequence.

Nor does one report prove mirror agreement. In client-side mirroring, RFC 8435 gives the client responsibility for updating every mirror and treats the write transaction as successful only if all copies are successfully updated. Errors can be reported to the metadata server, which may need to repair a mirror. An attribute set from one data file cannot testify for copies it did not observe.

The same separation applies above the file system. A metadata server may hold an accurate size while an application reads stale cached bytes. All storage copies may agree while the application requested the wrong file. Correct attributes, durable content and successful business use need different receipts.

Optionality preserves compatibility

RFC 9766 makes the new operation optional for NFSv4.2 and for the flexible file layout. That is a controlled compatibility choice. A client or server that does not implement operation 77 can remain interoperable through existing paths, including direct metadata-server queries. The cost may be more work, not automatic invalidity.

RFC 8178 supplies the extension discipline and RFCs 7862 and 7863 supply the NFSv4.2 protocol and XDR base. Those documents can establish the syntax and status of the operation. Only running endpoints can establish that support was negotiated and the operation exercised.

The security model is inherited from the flexible file layout. Loose coupling can use synthetic uid/gid values to fence cooperative clients, but it does not protect against a malicious client and cannot necessarily fence just one client. Tight coupling depends on its control protocol. Backend communication still needs protection against observation and tampering. An authenticated report from an authorized client proves who sent the report under that channel; it does not prove that every value represents the latest data-server state.

Sources

  1. RFC 9766: Extensions for Weak Cache Consistency in NFSv4.2's Flexible File Layout
  2. RFC 8435: Parallel NFS Flexible File Layout
  3. RFC 8434: Requirements for pNFS Layout Types
  4. RFC 1813: NFS Version 3 Protocol
  5. RFC 8881: NFS Version 4 Minor Version 1 Protocol
  6. RFC 7862: NFS Version 4 Minor Version 2 Protocol
  7. RFC 7863: NFSv4.2 XDR Description
  8. RFC 8178: Rules for NFSv4 Extensions and Minor Versions
  9. RFC 9754: Extensions for Opening and Delegating Files in NFSv4.2
  10. Running-Code Primacy
  11. Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  12. On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile