On Wed, Jun 11, 2025 at 9:28 AM David Noveck [off-list ref] wrote:

On Mon, Jun 9, 2025, 7:35 PM Rick Macklem [off-list ref] wrote:

quoted

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.

quoted

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.

quoted

Also, is the CB_RECALL needed when the delegation is held by
the same client as the one doing the REMOVE?

I think so.

From a practical point of view, I am not convinced it is needed.
The server can determine if the REMOVE actually deleted the
file and, if it did, can throw away any delegation record(s) for the
file object.
The client knows it has a delegation and can either DELEGRETURN
it or throw it away if it knows the file object has been deleted and the
associated file handle is no longer valid (it receives a NFS4ERR_STALE
from the server for it).

Also, wearing my pragmatic practitioner's hat, since the Linux knfsd
does not do a CB_RECALL now and has shipped this way to who
knows how many users, declaring that it must be CB_RECALL'd
does not seem useful?

rick

quoted

(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?)

This should be more clear.  Will be looking at a possible change in the next rfc5661bis draft.

quoted

Any comments? Thanks, rick
ps: I am amazed when I learn these things about NFSv4.n after all
      these years.

_______________________________________________
nfsv4 mailing list -- nfsv4@ietf.org
To unsubscribe send an email to nfsv4-leave@ietf.org