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

On Mon, Apr 15, 2024 at 4:06 PM David Noveck <davenoveck@gmail.com> wrote:
>
>
>
> 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".
I did a FreeBSD kernel build with both source and obj trees NFSv4.2
mounted. Here were the RPC counts:
Open/Create     Open/NoCreate     Remove    Rename
30083                9645                      27741       17254
--> So, there were more Removes+Renames than Opens. I have no way
     of knowing for sure, but most all of the files removed/renamed should
     have had delegations. (They would all be on the output obj side.)
Of course these RPC counts are dwarfed by:
Getattr          Lookup
1225717       485257

So, I guess it depends on what you consider as frequent? rick

>
>>
>> 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