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

On Mon, Apr 15, 2024, 6:31 PM Rick Macklem <rick.macklem@gmail.com> 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,

I don't think it is needed, although it is REQUIRED.

since it seems that the
> delegation stateid should be sufficient?
>

It should be.  As far as I can figure, it is most likely  due either to
inertia or a belt-and-suspenders approach to operation input.

> This new operation would be the same as DelegReturn except that
> it would not require a CFH argument.
>

It would be more correct to say it does not use the cfh as input.

> 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.
>
> A similar situation exists for Rename where the destination
> already exists.
>
> I find this scenario happens frequently during software builds.
>

I see that this can happen.  I'm not sure about "frequently".

> So, what do others think  w.r.t. this new operation? rick
>

I think you have made a reasonable case for this.  I suggest you submit an
I-D defining thus extension.  One issue you would need to address would be
providing a way for the client to determine if server support is present.

> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4
>