Re: [nfsv4] RFC: Is Open/Claim_Delegate_Prev done before/after Reclaim_complete?
Rick Macklem <rick.macklem@gmail.com> Sun, 07 April 2024 00:33 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 254B8C14F5ED for <nfsv4@ietfa.amsl.com>; Sat, 6 Apr 2024 17:33:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.096
X-Spam-Level:
X-Spam-Status: No, score=-7.096 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_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 Pg6l_Ib3vT_r for <nfsv4@ietfa.amsl.com>; Sat, 6 Apr 2024 17:33:46 -0700 (PDT)
Received: from mail-pf1-x430.google.com (mail-pf1-x430.google.com [IPv6:2607:f8b0:4864:20::430]) (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 4FE95C14F5EA for <nfsv4@ietf.org>; Sat, 6 Apr 2024 17:33:46 -0700 (PDT)
Received: by mail-pf1-x430.google.com with SMTP id d2e1a72fcca58-6ed20fb620fso185678b3a.2 for <nfsv4@ietf.org>; Sat, 06 Apr 2024 17:33:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1712450025; x=1713054825; 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=dz+/C0fsWi4cRTSoF/ZiYtLVPfcwOqm4xhnOSH0mhp4=; b=dewtsss6TyovhEgCaQL9OHyRwi4WbvcrtWqTO4t1an8wEeRnihtT/tNfeq7J6IC3Vt 5CC/swl3P/BPHuXdqx4IQuiafkS+uHkiDolvCvOUUnjLPOYd1yxMXf6VOvPq2fQqdaGf JWAxs9RB0n6/cvmZ3Z6Jjmux7gl572fh8MZ7mHFnW6Ctdrh4Jw42ZQnbNMD+Odt+qvQ2 uWhtusLOoEiFSP48DHsLiMIVHnLo1U6H38zAWBzjZ5lxlDbkGwknpCmJRejDdd0cNiUV 0LAQaVFesweLLObQ/wBg5Yg5amdOGkBwRt6NoL3awl8lK/tMHCMp9/zEczbf/iJu3mTm XLhA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712450025; x=1713054825; 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=dz+/C0fsWi4cRTSoF/ZiYtLVPfcwOqm4xhnOSH0mhp4=; b=YqfJcmnS6UhqRoL8Ynzyp489FtQLoWokZI77HKbJDUvw7GeyW/wfBiGGI+7ToOgeL4 tUZbcWbYYuhCMrEeHW9plRqalGB4q3TPPV9hz5uLHDX9eC9L6RuNjV7dmF4VT47m8MPA Pl/sZsp3NjoELI0yEjIfGl3UYdhMA4hO2OJgG7DuFJ+1F5C8/eXahfRhZUV5/b01OqT7 ocb5bMCq7EkKUQhNyUFoMxkqobWk9NJnb6nVdLnhIavpHcQALkMFLrIdk9HVS2S2X33Y g8ZylnFmlp28Z3cgDbATkBXVw9n1JGre/Y5lTAHWfiBlf2Yi56m/Nwo6pTv9DYQJHfKz uPNw==
X-Gm-Message-State: AOJu0YzYOK22OOroGFmNcbpWe0K8/x6q/VWu8OJj091i788L6RAPtae5 AByd8vjq3Y1kILyEznQzvsybo/HFQpFzhgpcsEVSzA44Dj+5JUN7xfvNC/OluFWYHhzuH3Kr1+u fCFt0R7VSFPBFDnaFgdUq1+bVuA==
X-Google-Smtp-Source: AGHT+IHfq58tuxofvElkwTmpql9LdKnnOHnESIytG6RnCn9LgLCYq94P2DUO/G/HkvPC41vmA0svNqPA2dwgJrHSSZU=
X-Received: by 2002:a05:6a21:3948:b0:1a7:236b:f1e6 with SMTP id ac8-20020a056a21394800b001a7236bf1e6mr4830978pzc.15.1712450025232; Sat, 06 Apr 2024 17:33:45 -0700 (PDT)
MIME-Version: 1.0
References: <CAM5tNy4y36AEyD5SeOZ2F1t8AYhu8-ZKPyNvCd-dmydFg1kJtA@mail.gmail.com> <CADaq8jdUd_6j0sq-1OFmtOAcX000a=2YbK3cZCg2QprLuXv3Qg@mail.gmail.com>
In-Reply-To: <CADaq8jdUd_6j0sq-1OFmtOAcX000a=2YbK3cZCg2QprLuXv3Qg@mail.gmail.com>
From: Rick Macklem <rick.macklem@gmail.com>
Date: Sat, 06 Apr 2024 17:33:35 -0700
Message-ID: <CAM5tNy5uwYHG2h0Djh9c1i=ZCiZUAL1i187oS+ooA_uPnBrdLQ@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/Y5MTWJuGYoLVwB7v_yOJSosiegE>
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:33:50 -0000
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 - 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
- [nfsv4] RFC: Is Open/Claim_Delegate_Prev done bef… Rick Macklem
- Re: [nfsv4] RFC: Is Open/Claim_Delegate_Prev done… Trond Myklebust
- Re: [nfsv4] RFC: Is Open/Claim_Delegate_Prev done… Rick Macklem
- Re: [nfsv4] RFC: Is Open/Claim_Delegate_Prev done… David Noveck
- Re: [nfsv4] RFC: Is Open/Claim_Delegate_Prev done… Trond Myklebust
- Re: [nfsv4] RFC: Is Open/Claim_Delegate_Prev done… Trond Myklebust
- Re: [nfsv4] RFC: Is Open/Claim_Delegate_Prev done… Rick Macklem
- Re: [nfsv4] RFC: Is Open/Claim_Delegate_Prev done… Rick Macklem
- Re: [nfsv4] RFC: Is Open/Claim_Delegate_Prev done… David Noveck
- Re: [nfsv4] RFC: Is Open/Claim_Delegate_Prev done… Rick Macklem
- Re: [nfsv4] RFC: Is Open/Claim_Delegate_Prev done… Rick Macklem
- Re: [nfsv4] RFC: Is Open/Claim_Delegate_Prev done… Rick Macklem
- Re: [nfsv4] RFC: Is Open/Claim_Delegate_Prev done… Rick Macklem
- Re: [nfsv4] RFC: Is Open/Claim_Delegate_Prev done… David Noveck
- Re: [nfsv4] RFC: Is Open/Claim_Delegate_Prev done… Rick Macklem
- Re: [nfsv4] RFC: Is Open/Claim_Delegate_Prev done… Rick Macklem
- Re: [nfsv4] RFC: Is Open/Claim_Delegate_Prev done… Rick Macklem
- Re: [nfsv4] RFC: Is Open/Claim_Delegate_Prev done… Rick Macklem