Re: [nfsv4] RFC: New DelegReturn_NoFH operation for NFSv4.2?

[Rick Macklem <[e-mail]>]

On Mon, Apr 15, 2024 at 3:31 PM Rick Macklem <[e-mail]> wrote:
>
> Hi,
>
> I am wondering if others have found this a pita and are interested in
> a new operation for NFSv4.2 to get around it.
>
> Right now DelegReturn requires a CFH and delegation stateid.
> I do not know why the CFH is needed, since it seems that the
> delegation stateid should be sufficient?
>
> This new operation would be the same as DelegReturn except that
> it would not require a CFH argument.
>
> Why am I interested in this?
> - Lets assume a NFSv4.2 server that supports persistent FHs and
>   multiple hard links (as most extant servers do).
> - A client mounted to this server is removing a file for which it holds
>   a write delegation and a bunch of dirty data.
> Right now, the client must:
> - Write the dirty data back to the server.
> - DelegReturn
> - Remove
> because the client has no way of knowing if the file will be deleted
> by the Remove (or alternately is just removing one of several hard links).
>
> With a DelegReturn_NoFH, the client could:
> - Do a compound RPC with
>   Remove
>   PutFH of file
> - if the above returns NFS_OK, the file still exists and the client
>   can continue to use the delegation, writing the dirty data back
>   to the server sometime later (or maybe never, if the file gets
>    deleted by a subsequent Remove).
> or
> - If the above returns NFS4ERR_STALE for the PutFH, the file
>   has been deleted. It can throw the dirty data away and
>   DelegReturn_NoFH the delegation.
Oops, I should have read the RFC first. I found this snippet:
   The following events necessitate recall of an OPEN delegation:

   *  potentially conflicting OPEN request (or a READ or WRITE operation
      done with a special stateid)

   *  SETATTR sent by another client

   *  REMOVE request for the file

   *  RENAME request for the file as either the source or target of the
      RENAME

I thought that the recall for REMOVE and RENAME only applied to
clients other than the one issuing the operation. However, this might
only apply to cases where the file handles will no longer be valid on
the server?

The FreeBSD NFSv4.1/4.2 server currently only recalls the delegations
for other clients than the one issuing the REMOVE or RENAME.
Is this a bug?

rick

>
> A similar situation exists for Rename where the destination
> already exists.
>
> I find this scenario happens frequently during software builds.
>
> So, what do others think  w.r.t. this new operation? rick