Two clients read the same export and see a change at different times. Before labeling the behavior a broken cache, ask which information was cached, what operation should trigger validation, and which consistency contract the application expects.
“The NFS cache” is not one object. Data pages, inode attributes, pathname lookup results, and directory entries serve different purposes. Changing a metadata validation interval can increase RPC traffic without doing what you expect to cached file data.
A cached read still has a consistency story
The Linux NFS client can satisfy data reads from its page cache when the cached state remains usable. Attribute information helps determine whether remote changes require invalidation or revalidation. The relevant operations and policies depend on protocol version and mount configuration.
Close-to-open consistency is a useful common model: one client closes a file after changes, and a subsequent open on another client checks state so it can see those changes under the protocol’s expected behavior. It is not a promise that all concurrent readers holding an already-open file observe every write immediately.
For an application requiring stronger coordination, use a designed protocol—appropriate locking, versioning, or a single-writer arrangement—rather than assuming a shorter timeout creates transactions. NFSv4 delegations and stateful mechanisms add further considerations.
Names and attributes can dominate small operations
A directory-heavy workload may spend more time on lookup and attribute operations than on transferring file contents. ls -l may ask for information that a names-only listing does not need. Valid entries and attributes can avoid work, while invalidation or cache misses generate additional requests.
This is why a throughput-oriented setting such as rsize does not necessarily fix a slow directory listing. rsize and wsize concern read/write transfer sizes; they are not general-purpose directory batch sizes or direct replacements for TCP socket buffers.
Use the NFS listing walkthrough to separate the application operation from its RPC mix.
Buffered writes are not a durability receipt
An application can modify client-side cached pages before the client sends all data to the server. Client writeback and server stable-storage requirements are separate stages. NFSv3’s unstable-write and COMMIT behavior makes that distinction explicit.
Applications must check errors at the relevant write and synchronization boundaries. A successful buffered write is not proof that the server’s storage has persisted the data. Conversely, a later error can report a problem with earlier buffered work.
For a consistency or durability experiment, record exactly what calls the application makes, including synchronization and close behavior. Do not compare a buffered workload with a synchronized workload and call the difference a cache optimization.
Inspect before disabling caching
Read-only inventory on an authorized client:
nfsstat -m
nfsstat -c
cat /proc/self/mountstats
findmnt -t nfs,nfs4Check the effective options rather than assuming the requested values were negotiated unchanged. For a disposable two-client experiment, write a known version on one client and record when the other observes it under both reopen and held-open patterns. Keep the files non-sensitive and the write/sync sequence explicit.
Record operation counters, elapsed time, payload sizes, directory size, and warm/cold conditions. Do not drop global caches on a shared host or modify a production mount merely to obtain a cleaner chart.
Caching settings trade load for validation
Reducing attribute caching can increase metadata requests and server pressure. Options commonly described as “no cache” may affect only certain kinds of caching or validation; read the Linux documentation rather than inferring semantics from a name.
Larger read-ahead or transfer sizes can help sequential workloads while wasting bandwidth for sparse access. More client concurrency can saturate the server, NIC, or storage backend and worsen tail latency. Performance depends on workload shape and the consistency/durability contract, not a universally best mount string.
Treat cache-policy changes as experiments with correctness checks. The goal is to explain stale observations and measure the effect of a change under the application’s consistency contract.
Further reading
Primary references behind this explanation. Consult documentation for the version and environment you actually run.