Re: simple NFSv4.1/4.2 test of remove while holding a delegation

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.

If the REMOVE was done by another client, the REMOVE will not complete
until the delegation is returned. If the PUTFH comes after the REMOVE
was completed, it'll  fail with NFS4ERR_STALE since the file, specified
by the file handle, no longer exists.

-Dai

> (I don't think it is, but there is a discussion in 18.25.4 which says
> "When the determination above cannot be made definitively because
> delegations are being held, they MUST be recalled.." but everything
> above that is a may/MAY, so it is not obvious to me if a server really
> needs to case?)
>
> Any comments? Thanks, rick
> ps: I am amazed when I learn these things about NFSv4.n after all
>        these years.
>