The NFS updates merged for the Linux 7.3 window include the piece that was deliberately left out last time. NFSD now supports CB_NOTIFY for NFSv4.1 directory delegations, which means a server can tell a client exactly what changed in a delegated directory instead of yanking the delegation and forcing a full refetch. The change events come from fsnotify, so additions, removals, renames and directory attribute changes all qualify. Recall only delegations landed first, in 2025, with CB_NOTIFY explicitly postponed until the simpler version had seen real use. This is the follow up, and it is the half that makes LOOKUP heavy workloads faster.
The short answer
The NFS updates merged for the Linux 7.3 window give NFSD CB_NOTIFY support for NFSv4.1 directory delegations. Instead of recalling a delegation whenever a directory changes, the server can encode a description of the change and send it to the client, which applies the delta and keeps the rest of its cache. The events come from fsnotify and cover additions, removals, renames and directory attribute changes. Recall only delegations landed in 2025 with CB_NOTIFY deliberately postponed. The same pull continues NFSD's Netlink work and drops the alternative service thread pool modes.
Most NFS latency that people complain about is not throughput. It is the cost of finding out whether a file exists. Linux 7.3 does something about that, and it does it by finishing a job that was consciously left half done a year ago.
The problem with recall only
Directory delegations are the directory equivalent of the file delegations NFS has had for years. A client uses the NFSv4.1 GET_DIR_DELEGATION operation to ask for one, and while it holds it, it knows nothing inside that directory will change without the server telling it. That means LOOKUP and readdir can be answered locally, without a round trip and without the guesswork of attribute cache timeouts.
Jeff Layton's implementation for knfsd landed as recall only. That was a deliberate choice, stated plainly at the time: ship the smaller thing, get experience with it, add notifications in a later kernel.
Recall only works, but it is blunt. Any change to the directory means the server takes the delegation back, and the client discards the whole cached picture and starts again. On a directory that is mostly stable that is fine. On a directory that gets one new file every few minutes, it is a treadmill, and the delegation can end up costing more than it saves.
What CB_NOTIFY changes
NFSD in Linux 7.3 can now send a CB_NOTIFY callback instead. Rather than revoking the promise, the server describes what happened.
The mechanism is straightforward. Change events arrive through fsnotify, the kernel's existing file change notification machinery, which is why the coverage is what it is: creations, removals, renames and changes to the directory's own attributes. The server encodes the event as XDR into a buffer attached to the delegation, queues the callback, and the callback picks up that buffer while a fresh one starts collecting the next batch. Events accumulate and go out together rather than one syscall at a time.
The result is proportionality. One file appearing in a directory of ten thousand entries costs one small notification, not a recall followed by a full re enumeration.
Why LOOKUP is the workload that matters
Open a file at a path six directories deep over NFS and you have issued a chain of LOOKUP calls, one per component. Do that across a build tree, a CI checkout or a dependency directory holding tens of thousands of small files and the LOOKUP traffic dominates everything else on the mount.
Without a delegation, each of those lookups is governed by attribute cache timeouts. The client is guessing about staleness, and the tuning advice people trade around is really advice about how much wrongness to tolerate. A delegation replaces the guess with a guarantee, and CB_NOTIFY makes that guarantee survivable on directories that actually change.
The clearest evidence for the size of the win comes from outside Linux. Rick Macklem demonstrated a FreeBSD implementation of directory delegations at an NFS Bakeathon precisely on the grounds that it greatly improves LOOKUP heavy workloads. The mechanism is the same protocol feature, so the reasoning carries.
The rest of the pull
Two other items are worth noting for anyone running NFS servers.
NFSD continues building out Netlink support, work that started in the previous cycle. That is the direction of travel across the kernel: configuration and introspection through Netlink rather than an accumulation of procfs files and sysctls.
More immediately visible, the alternative NFSD service thread pool arrangements have been removed, leaving per node handling as the only mode. The reasoning is that per node is the right answer on any machine running NFS today. If you have a tuning script that sets a thread pool mode, it is worth finding out now whether it was ever doing anything useful on your hardware, because after 7.3 it will not have anything to set.
When you can use it
Not soon, and that is normal. This is server side work, and a delegation needs a client that asks for one and understands the callback. The Linux client pieces are on their own schedule.
Linux 7.2 shipped in mid August 2026, which puts 7.3 at the end of its merge window now and a stable release roughly two months out on the usual cadence. Distribution kernels come later still, and NFS is not a subsystem where sensible people rush. The 7.3 networking merge window closed on August twentieth, and the same cycle brought Btrfs direct I/O improvements worth up to 5x, so there is a pattern to this release: unglamorous plumbing, measured in round trips saved.
Sources and further reading
- NFS Improvements Arrive For Linux 7.3, Phoronix, August 2026
- vfs, nfsd, nfs: implement directory delegations, LWN.net
- vfs: recall only directory delegations for knfsd, LWN.net, October 17, 2025
- NFSv4.1: Directory Delegations and Notifications, IETF draft
- CITI Experience with Directory Delegations, Linux NFS wiki
Frequently asked questions
What is a directory delegation, in one paragraph?
It is a promise from an NFS server to a client about a specific directory. NFSv4.1 adds a GET_DIR_DELEGATION operation that a client can use to ask for one. While the client holds it, it knows that the entries in that directory will not change without the server saying so, which means it can answer LOOKUP and readdir requests out of its own cache instead of going over the wire every time. File delegations have existed for far longer and work on the same principle. Directories were the harder case, because a directory changes whenever anything inside it is created, deleted or renamed.
What does CB_NOTIFY add that recall did not?
Proportionality. With recall only delegations, any change to the directory means the server takes the delegation back, and the client throws away everything it had cached about that directory and refetches. That is correct but expensive, and on a directory that changes often it can be worse than never having had a delegation. CB_NOTIFY lets the server send a description of the change instead. The client applies the delta and keeps the rest of its cache. One file appearing in a directory of ten thousand entries stops costing a full re enumeration.
Which workloads actually benefit?
Anything LOOKUP heavy, which in practice means anything that walks paths. Shared build trees over NFS, home directories, CI checkouts, dependency directories with tens of thousands of small files, and mail spools in Maildir format are the classic cases. Every stat of a deep path is a chain of LOOKUP calls, and without a delegation each link in that chain is a round trip governed by cache timeouts rather than by knowledge. The FreeBSD implementation of directory delegations was demonstrated at an NFS Bakeathon specifically on the grounds that it greatly improves LOOKUP heavy workloads.
Can I use this as soon as I install a 7.3 kernel?
Not on its own. This is server side work in NFSD, and a delegation is a two party arrangement, so the client has to ask for one and know what to do with a CB_NOTIFY callback. The Linux client side pieces have been landing separately and on their own schedule. Linux 7.2 shipped in mid August 2026, so 7.3 is only now leaving its merge window and a stable release is roughly two months out on the usual cadence, with distribution kernels later still. Plan on this being something you evaluate in 2027 rather than something you switch on this quarter.
What else is in the Linux 7.3 NFS pull?
Two things worth knowing about. NFSD continues to build out the Netlink support that started in the previous cycle, which is the modern way of configuring and inspecting kernel subsystems rather than through the older procfs and sysctl surfaces. Separately, the alternative NFSD service thread pool arrangements have been removed, leaving per node handling as the single mode, on the reasoning that it is the right choice for any host running NFS today. That is a small simplification with a real benefit: one fewer tuning knob that people were setting on the basis of advice written for very different hardware.