Closed chucklever closed 7 months ago
[Chuck Lever 2023-02-05 17:05:19 UTC] RFC 1813 says:
In the NFS version 3 protocol, each READDIR request includes both a cookie and a cookie verifier. For the first call, both are set to 0. The response includes a new cookie verifier, with a cookie per entry. For subsequent READDIRs, the client must present both the cookie and the corresponding cookie verifier. If the server detects that the cookie is no longer valid, the server will reject the READDIR request with the status, NFS3ERR_BAD_COOKIE. The client should be careful to avoid holding directory entry cookies across operations that modify the directory contents, such as REMOVE and CREATE. One implementation of the cookie-verifier mechanism might be for the server to use the modification time of the directory. This might be overly restrictive, however. A better approach would be to record the time of the last directory modification that changed the directory organization in a way that would make it impossible to reliably interpret a cookie. Servers in which directory cookies are always valid are free to use zero as the verifier always.
[Chuck Lever 2023-02-05 17:12:39 UTC]
Servers in which directory cookies are always valid are free to use zero as the verifier always.
It appears that Linux NFSD exports some filesystems (such as tmpfs) where individual cookies can change after a directory modification. The specification is not normative about this, so we can claim spec compliance. However, it can be argued that because NFSD always returns a zero cookie verifier, it is not properly advertising potential modification of the cookie-to-entry mapping in each directory.
Therefore I'm changing this item from "enhancement request" to "bug".
[Jeff Layton 2023-02-06 16:03:02 UTC] Sounds reasonable. Maybe we could just stuff the i_version for the directory into that field, and maybe only do that for filesystems that don't claim to have stable dir cookies?
I implemented verifier cookies and it did not address the cookie change problem described above. However I implemented stable directory offsets for tmpfs, and it did address the issue. Therefore, this will remain marked as an enhancement and as "WONTFIX" -- there does not seem to be any palpable benefit to providing directory cookies.
This was bugzilla.linux-nfs.org 404
[Chuck Lever 2023-02-03 23:03:12 UTC] Some filesystems do not have stable readdir cookies. This means that after a directory is modified (and entry added or removed) the cookies/offsets can change.
Apparently the protocol's directory verifier can be used to signal to a client that directory content has changed so that it knows it needs to re-read the directory and not depend on cached content.
Today NFSD simply returns the verifier that the client sent: usually all zeroes. It would be better if NFSD could use the verify to indicate directory volatility.