On Wed, Jun 11, 2025 at 9:28 AM David Noveck <davenoveck@xxxxxxxxx> wrote: > > > > On Mon, Jun 9, 2025, 7:35 PM Rick Macklem <rick.macklem@xxxxxxxxx> wrote: >> >> Hi, >> >> I hope you don't mind a cross-post, but I thought both groups >> might find this interesting... > > > I find it interesting, but I can't speak.for either group. >> >> >> 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? > > > I think they are both correct. It seems to me that an attempt to choose one of these as preferred and deprecating the other should be rejected since it unjustiably imposes a particular design choice on the server. >> >> >> Also, is the CB_RECALL needed when the delegation is held by >> the same client as the one doing the REMOVE? > > > I think so.
