> On Aug 8, 2022, at 4:06 PM, Chuck Lever III <chuck.lever@xxxxxxxxxx> wrote: > >> On Aug 8, 2022, at 2:48 PM, Jeff Layton <jlayton@xxxxxxxxxx> wrote: >> >> On Mon, 2022-08-08 at 09:52 -0400, Chuck Lever wrote: >>> This RFC series adds logic to the Linux NFS server to make it wait a >>> few moments for clients to return a delegation before replying with >>> NFS4ERR_DELAY. There are two main benefits: >>> >>> - This improves responsiveness when a delegated file is accessed >>> from another client >>> - This removes an unnecessary latency if a client has neglected to >>> return a delegation before attempting a RENAME or SETATTR >>> >>> This series is incomplete: >>> - There are likely other operations that can benefit (eg. OPEN) > >> Does REMOVE need similar treatment? Does the Apple client return a >> delegation before attempting to unlink? > > It's certainly plausible that REMOVE might trigger a delegation recall, > but I haven't yet seen this happen on the wire. I started playing with REMOVE and DELEG15a, and ran into an interesting problem. REMOVE is passed the filehandle of the parent and the name of the entry to be removed. nfsd4_remove() doesn't have an inode or filehandle of the object to be removed. nfsd_unlink() does acquire the inode of that object, though. And, I guess if we want to avoid NFSv3 operations returning JUKEBOX on delegated files too, the "wait for DELEGRETURN" really ought to be called from the fs/nfsd/vfs.c functions, not from the NFSv4 specific functions in fs/nfsd/nfs4proc.c. -- Chuck Lever
