NFSD should support directory cookie verifiers

[chucklever]

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.

[chucklever]

[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.

[chucklever]

[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".

[chucklever]

[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?

[chucklever]

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.