NetworkNews

Linux 7.3 NFSD: notifying a cache instead of recalling it

On this page
  1. A different response to directory changes
  2. Follow one rename
  3. A server feature needs a cooperating client

NFSD’s Linux 7.3 update adds CB_NOTIFY for NFSv4.1 directory delegations. The useful change is that a server can report a directory modification so a cooperating client can maintain its cache, instead of immediately recalling the delegation.

Conceptual rename example: a server changes report.txt to final.txt; an applicable notification lets a cooperating client update that cached entry while keeping notes.txt. Not a wire-protocol trace.
Conceptual rename example: a server changes report.txt to final.txt; an applicable notification lets a cooperating client update that cached entry while keeping notes.txt. Not a wire-protocol trace. Chart : PeopleAreGeek. Data source.
View full-size image

A different response to directory changes

The NFSD release notes say the server monitors delegated directories with fsnotify. Notifications cover additions, removals, renames and directory attribute changes, including information about affected entries.

Recall and notification are different operations. A recall asks the client to return its delegation; a notification communicates a change. Describing CB_NOTIFY as merely “recalling sooner” misses the reason for this work.

Follow one rename

Consider an illustrative directory cache containing two names: report.txt and notes.txt. A different client renames report.txt to final.txt on the server.

With an applicable notification, the first client can update the affected entry while retaining useful cached knowledge about notes.txt. That is the conceptual benefit. The example does not specify the exact on-wire encoding of a rename or promise that the client will avoid every subsequent request.

If the client cannot use the relevant notification or the delegation is recalled, it must follow the protocol's cache-consistency path. Keeping an old list indefinitely is not a valid substitute for handling that event.

A server feature needs a cooperating client

The NFSv4.1 protocol specification defines directory delegations and notification requests. The installed client, negotiated capabilities and actual workload matter. Merely upgrading the server does not establish that all existing mounts will start using the mechanism.

A practical evaluation would record both sides' versions, confirm whether a directory delegation was granted, then observe callbacks while a second client adds, removes and renames sample entries. Check the first client's visible names against the server state after each operation. Measure directory-related requests separately from bulk file transfer.

This is an original validation outline, not a test result. It targets the feature's intended effect: keeping directory knowledge useful across changes. It does not imply faster disk reads, a specific bandwidth gain or a universal reduction in NFS traffic.

When presenting results, retain cases where no delegation was granted. Otherwise a benchmark can silently compare a new notification path in one run with an ordinary cache path in another and attribute all differences to the kernel version.

Correct recall-versus-notify distinction and show a concrete directory rename example.