On Wed, Jun 11, 2025 at 1:57 PM Rick Macklem <rick.macklem@xxxxxxxxx> wrote: > > 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. > 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? > Btw, I did some quick tests with 3 NFSv4.1/4.2 clients. Linux 6.12, Solaris 11.4 and FreeBSD recent releases. For a REMOVE when the client holds a write delegation for the file object: - All 3 DELERETURN before REMOVE. For a RENAME when the client holds write delegations for both src and dst file object: - Solaris and FreeBSD DELEGRETURN both delegations before RENAME. - Linux DELEGRETURNs the dst delegation befor RENAME. (I believe Linux is correct in doing so, since the FreeBSD server reports a fh_expire_type of FH4_PERSISTENT, which I understand means "will still be valid after a RENAME".) As such, none of these extant NFSv4.1/4.2 clients will need a server to CB_RECALL any delegation for REMOVE or RENAME. It is the experimental NFSv4.1/4.2 client I am playing with that does not do DELEGRETURNs before REMOVE or RENAME, which is why I am now trying to determine allowable/correct behaviour. Thanks everyone for your comments, rick > rick > > > > >> (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. > >> > >> > >> Any comments? Thanks, rick > >> ps: I am amazed when I learn these things about NFSv4.n after all > >> these years. > >> > >> _______________________________________________ > >> nfsv4 mailing list -- nfsv4@xxxxxxxx > >> To unsubscribe send an email to nfsv4-leave@xxxxxxxx
