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

Rick Macklem <rick.macklem@gmail.com> Sun, 07 April 2024 00:55 UTC

Return-Path: <rick.macklem@gmail.com>
X-Original-To: nfsv4@ietfa.amsl.com
Delivered-To: nfsv4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE63EC14F5F5 for <nfsv4@ietfa.amsl.com>; Sat, 6 Apr 2024 17:55:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level:
X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ygPyQeh3LRKm for <nfsv4@ietfa.amsl.com>; Sat, 6 Apr 2024 17:55:10 -0700 (PDT)
Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com [IPv6:2607:f8b0:4864:20::102d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D0ACC14F5EC for <nfsv4@ietf.org>; Sat, 6 Apr 2024 17:55:10 -0700 (PDT)
Received: by mail-pj1-x102d.google.com with SMTP id 98e67ed59e1d1-29b7164eef6so2707504a91.2 for <nfsv4@ietf.org>; Sat, 06 Apr 2024 17:55:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1712451310; x=1713056110; darn=ietf.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=/CiHhsdMi6M0vB0gC/iVD+0Lippo4RiODLxOGhcYKtE=; b=D48kv9Bl6TaDEUMnrBLmcCcU55K/6dWXAepVRW/5hOP68u3ocLNdM68EKfBzS5VfRM 90lxml61l1dMBqIljUJvytvO26WbnUeljE7Xsp1TlYtQ1isT14OseyyFbJEeVzVfEQSu XZvNqVNfR8THX/ZuhTlCZZwOrp4/AXpsC0svE/vql3rcccQG8ghjcpBxk2PpL/vXic2A 26efhi/opSgOyDWVKhVLZh70B/JN8WNqj8ADzwfPmIACvurTgz9Z4C3gKHtUYozlTEQI 59Tu29QoXaIfQLwsPNI9XzcackGgc9TQLR+DumjTzqKp0VphmaCJRz9xudiTlOTQ2ua9 qeng==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712451310; x=1713056110; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=/CiHhsdMi6M0vB0gC/iVD+0Lippo4RiODLxOGhcYKtE=; b=hyR9/x6Wc0gXHk4JOx7Cx3kL6fU3mkA2ULAcYplwOtE6vkhvP9VCsEJzBkXYTL1wiE Cyme4/xBQ9+4fZnSbggeCJVzW4NsfA1wf7DMvTH5UFyU8oZ6uw798s/3itglE2eHfpzw ObIHDig2uWeH0590lefi0jxRy7ZljU2U1fIIAZzULjQ4+N4TEPrOmrwg+ym/RwqKvayK h9TzXSbGCrE6f1c+22rXREvlqoOZJFhqeRyinok2BFZUjNVG8VJtdMd25HbCcSZTqxM0 GoLkGKRo/bPM9lLEy+9BE3wv+cwCao1Eg3l4bceuhXIZQJNHJGLpOhk5b58ItoACiQoV cRAg==
X-Gm-Message-State: AOJu0YydtCygM1Tiscn0v3NPyRqIlKhgDt0NN6Ius3S/Tm61Dk8uj10D 4084KAklGd/Y7qFEtUQUZS9hRPA509khoFlcN9sHqeaHcRnXx+eY9310lqNd5Eg281CL6s0XP0K gZLxYvs214557W8HF7zMQ/HwfSQ==
X-Google-Smtp-Source: AGHT+IGwjHnC03KK30Yh36ZRKwRZFZzCpgQTvLqF/AceiY932FiBW5KexaC/vvnesosQiPyB4+ESKwX73QhNwgjzKdU=
X-Received: by 2002:a17:90a:fe8d:b0:2a2:ba9:ba61 with SMTP id co13-20020a17090afe8d00b002a20ba9ba61mr5133703pjb.34.1712451309671; Sat, 06 Apr 2024 17:55:09 -0700 (PDT)
MIME-Version: 1.0
References: <CAM5tNy4y36AEyD5SeOZ2F1t8AYhu8-ZKPyNvCd-dmydFg1kJtA@mail.gmail.com> <CADaq8jdUd_6j0sq-1OFmtOAcX000a=2YbK3cZCg2QprLuXv3Qg@mail.gmail.com> <CAM5tNy5uwYHG2h0Djh9c1i=ZCiZUAL1i187oS+ooA_uPnBrdLQ@mail.gmail.com>
In-Reply-To: <CAM5tNy5uwYHG2h0Djh9c1i=ZCiZUAL1i187oS+ooA_uPnBrdLQ@mail.gmail.com>
From: Rick Macklem <rick.macklem@gmail.com>
Date: Sat, 06 Apr 2024 17:55:00 -0700
Message-ID: <CAM5tNy5MSbh1bjaQhQS+5sO10o_eP8q2gGQ6DC20ybqLJD4PNw@mail.gmail.com>
To: David Noveck <davenoveck@gmail.com>
Cc: NFSv4 <nfsv4@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/rIjilGw91u5rkLgFPNM92K_ZFoc>
Subject: Re: [nfsv4] RFC: Is Open/Claim_Delegate_Prev done before/after Reclaim_complete?
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nfsv4/>
List-Post: <mailto:nfsv4@ietf.org>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 07 Apr 2024 00:55:15 -0000

On Sat, Apr 6, 2024 at 5:33 PM Rick Macklem <rick.macklem@gmail.com> wrote:
>
> On Fri, Apr 5, 2024 at 12:50 PM David Noveck <davenoveck@gmail.com> wrote:
> >
> >
> >
> > On Thu, Apr 4, 2024 at 7:23 PM Rick Macklem <rick.macklem@gmail.com> 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.
> It may be, but I am now thinking it is a feature and not a bug.
> Why?
> Well, I now think that it is preferable for the client to use
> Open/Claim_previous instead of Open/Claim_delegate_prev when
> the server is in grace. (One reason is that the client is guaranteed to
> get a delegation for Open/Claim_previous, which would allow it to write
> dirty data back to the server if the reply specifies an immediate recall.
>
> Here is how I am currently thinking the algorithms could go:
> On the server...
> - When the server receives a ExchangeID/Create_session with the
>   same co_ownerid but different co_verifier as a clientid it already has
>   - Mark all extant delegations OLD
>
> - When the server receives a Open/Claim_delegate_prev
>    - if in grace
>          - reply NFS4ERR_GRACE
>    - search the delegation list for a matching one (same FH) marked OLD
>      - if found
>          - clear the OLD mark and keep it
>          - reply to Open successfully
>      - else
>          - reply NFS4ERR_BAD_RECLAIM
Oops, my bad...it's NFS4ERR_RECLAIM_BAD, no pun intended, rick

>
> - When the server receives Reclaim_complete, discard all delegations
>    marked OLD
>
> On the client when it reboots and has delegations it wishes to recover...
> - Do a ExchangeID/Create_session with same co_ownerid and
>   different co_verifier
>   - use_claim_previous = false
>   - for each delegation it wishes to recover
>  tryagain:
>     - if use_claim_previous
>        - do an Open/Claim_previous
>     - else
>        - do an Open/Claim_delegate_prev
>          - if the reply is NFS4ERR_GRACE
>            - use_claim_previous = true
>            - goto tryagain
>     - if the reply is NFS4ERR_BAD_RECLAIM
>         - deal with ugly case of no recovered delegation
> - Do a Reclaim_complete
>
> Basically, having Open/Claim_delegate_prev reply NFS4ERR_GRACE is
> an easy way for the client to test if the server is in grace.
>
> >
> >>
> >> 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.
> One more item. The text for Sec. 18.16 allows Open/Claim_delegate_prev
> to be used with Create. I cannot think why a Create case would be useful?
>
> rick
>
> >
> >>
> >> _______________________________________________
> >> nfsv4 mailing list
> >> nfsv4@ietf.org
> >> https://www.ietf.org/mailman/listinfo/nfsv4