Re: [nfsv4] RFC: Is Open/Claim_Delegate_Prev done before/after Reclaim_complete?

[Rick Macklem <[e-mail]>]

On Fri, Apr 5, 2024 at 12:50 PM David Noveck <[e-mail]> wrote:
>
>
>
> On Thu, Apr 4, 2024 at 7:23 PM Rick Macklem <[e-mail]> wrote:
>>
>> Hi,
>>
>> I am in the process of implementing Open/Claim_Delegate_Prev and have run
>> into a question I cannot seem to answer from reading RFC8881.
>
>
> Let me see if I can make this clearer in rfc5661bis-04.  Fingers croosed.
>>
>>
>> There is this snippet:
>>    enum open_claim_type4 {
>>            /*
>>             * Not a reclaim.
>>             */
>>            CLAIM_NULL              = 0,
>>
>>            CLAIM_PREVIOUS          = 1,
>>            CLAIM_DELEGATE_CUR      = 2,
>>            CLAIM_DELEGATE_PREV     = 3,
>>
>>            /*
>>             * Not a reclaim.
>>             *
>>             * Like CLAIM_NULL, but object identified
>>             * by the current filehandle.
>>             */
>>            CLAIM_FH                = 4, /* new to v4.1 */
>> The comments in the above seem to "hint" that CLAIM_DELEGATE_PREV is a
>> reclaim type operation.
>> If that is the case, I'd assume it/should be performed by the client
>> before it does a
>> Reclaim_Complete?
>
>
> I think that's right.
>>
>>
>> Then there is this snippet:
>>    For OPEN requests that reach the server during the grace period, the
>>    server returns an error of NFS4ERR_GRACE.  The following claim types
>>    are exceptions:
>>
>>    *  OPEN requests specifying the claim type CLAIM_PREVIOUS are devoted
>>       to reclaiming opens after a server restart and are typically only
>>       valid during the grace period.
>>
>>    *  OPEN requests specifying the claim types CLAIM_DELEGATE_CUR and
>>       CLAIM_DELEG_CUR_FH are valid both during and after the grace
>>       period.  Since the granting of the delegation that they are
>>       subordinate to assures that there is no conflict with locks to be
>>       reclaimed by other clients, the server need not return
>>       NFS4ERR_GRACE when these are received during the grace period.
>> This clearly states that CLAIM_DELEGATE_PREV cannot be performed
>> during the server's grace period.
>>
>
> It seems to me that this is an oversight.
>
>>
>> The above two statements are not necessarily contradictory but it does seem
>> that, if the server is in its grace period, the Reclaim_Complete needs to be
>> done before any Open/Claim_Delegate_Prev, since Reclaim_Complete tells
>> the server when to end its grace period.
>
>
> Yes.
>
>>
>> Note that, usually, a client would not be rebooting when a server is in its
>> grace period, but that could happen.
>
>
> Yes it can.  It wouldn't matter if you said "MUST NOT" or "IST STRENG VERBOTEN".
>>
>>
>> Bottom line...
>> Should a client perform Open/Claim_Delegate_Prev before or after
>> Reclaim_Complete?
>
>
> Before.
>
>>
>> And, if the answer is "after", how does the server know when a client
>> is done recovering opens/delegations via Open/Claim_Delegate_Prev?
>>
> That's why "after" is not a good answer.
>
>>
>> Thanks for any help with this, rick
>>
> Thanks for bringing this up.
First, here's some background to why I asked this...
The FreeBSD server has had a dormant implementation in it, done for
NFSv4.0. I am now working on an experimental client side caching
mechanism that caches agressively on non-volatile storage when a
delegation for the file is held by the client.
I would like to be able to recover the delegations after a client reboot,
so that the cached data still remains valid. (For the case of a write
delegation with dirty cached data, loosing the delegation leaves it
in a "very awkward situation".)
This is why I have become interested in the use of Open/Claim_delegate_prev.

For the case where the server is not in grace, doing the
Open/Claim_delegate_prev
opens before Reclaim_complete does seem appropriate and straightforward.
- The client does an ExchangeID with same co_ownerid but a different
co_verifier,
  followed by a Create_session to confirm it.
- The server marks all extant delegations for the client OLD.
- The client recovers the delegations it wants via Open/Claim_delegate_prev.
- If an Open request that conflicts with an OLD delegation is received
by the server,
  it gets NFS4ERR_DELAY.
- When the client does Reclaim_complete, all OLD delegations are discarded.
The alternative of doing them after Reclaim_complete would require some sort of
timeout on the OLD delegations (one lease time?) after which the
server would discard
them, at least if there was a conflicting Open request.

Now, for the case where the server is in grace:
- The client does an ExchangeID with same co_ownerid but a different
co_verifier,
  followed by a Create_session to confirm it.
- The server just treats this as a new clientID and there are no
delegations for the
  client to mark OLD.
Now, the client has two choices for recovering the delegations.
a) - Use Open/Claim_previous.
OR
b) - Use Open/Claim_delegate_prev (if allowed during grace).
So, if the spec. is changed to allow Claim_delegate_prev during grace, then I
think this should work as well, assuming the server is willing to handle a
Open/Claim_delegate_prev in the same manner as an Open/Claim_previous.
- Then the client would do a Reclaim_complete after recovering the delegations.

So, I think that David's proposal of allowing Open/Claim_delegate_prev during
grace and doing it before Reclaim_complete should work ok.

If what is proposed by Tom's draft can be used to indicate "client only wants a
delegation and no open" can be used for Open/Claim_delegate_prev, that would
seem a bonus.

Thanks for the comments, rick


>
>>
>> _______________________________________________
>> nfsv4 mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/nfsv4