On Tue, 10 Jun 2025 at 02:17, Dai Ngo <dai.ngo=40oracle.com@xxxxxxxxxxxxxx> wrote: > > On 6/9/25 4:35 PM, Rick Macklem wrote: > > Hi, > > > > I hope you don't mind a cross-post, but I thought both groups > > might find this interesting... > > > > I have been creating a compound RPC that does REMOVE and > > then tries to determine if the file object has been removed and > > I was surprised to see quite different results from the Linux knfsd > > and Solaris 11.4 NFSv4.1/4.2 servers. I think both these servers > > provide FH4_PERSISTENT file handles, although I suppose I > > should check that? > > > > First, the test OPEN/CREATEs a regular file called "foo" (only one > > hard link) and acquires a write delegation for it. > > Then a compound does the following: > > ... > > REMOVE foo > > PUTFH fh for foo > > GETATTR > > > > For the Solaris 11.4 server, the server CB_RECALLs the > > delegation and then replies NFS4ERR_STALE for the PUTFH above. > > (The FreeBSD server currently does the same.) > > > > For a fairly recent Linux (6.12) knfsd, the above replies NFS_OK > > with nlinks == 0 in the GETATTR reply. > > > > Hmm. So I've looked in RFC8881 (I'm terrible at reading it so I > > probably missed something) and I cannot find anything that states > > either of the above behaviours is incorrect. > > (NFS4ERR_STALE is listed as an error code for PUTFH, but the > > description of PUTFH only says that it sets the CFH to the fh arg. > > It does not say anything w.r.t. the fh arg. needing to be for a file > > that still exists.) Neither of these servers sets > > OPEN4_RESULT_PRESERVE_UNLINKED in the OPEN reply. > > > > So, it looks like "file object no longer exists" is indicated either > > by a NFS4ERR_STALE reply to either PUTFH or GETATTR > > OR > > by a successful reply, but with nlinks == 0 for the GETATTR reply. > > > > To be honest, I kinda like the Linux knfsd version, but I am wondering > > if others think that both of these replies is correct? > > > > Also, is the CB_RECALL needed when the delegation is held by > > the same client as the one doing the REMOVE? > > The Linux NFSD detects the delegation belongs to the same client that > causes the conflict (due to REMOVE) and skips the CB_RECALL. This is > an optimization based on the assumption that the client would handle > the conflict locally. Does Linux nfsd have a setting to turn such optimizations OFF (all of them)? Ced -- Cedric Blancher <cedric.blancher@xxxxxxxxx> [https://plus.google.com/u/0/+CedricBlancher/] Institute Pasteur
