IETF Logo Mail Archive

Re: [nfsv4] handling GETATTR vs. fh with outstanding write delegation

David Noveck <davenoveck@gmail.com> Fri, 26 May 2023 12:49 UTC

Return-Path: <davenoveck@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 EF647C17B327 for <nfsv4@ietfa.amsl.com>; Fri, 26 May 2023 05:49:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.094
X-Spam-Level:
X-Spam-Status: No, score=-2.094 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, HTML_MESSAGE=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 GbzAFlsXq_No for <nfsv4@ietfa.amsl.com>; Fri, 26 May 2023 05:49:56 -0700 (PDT)
Received: from mail-qv1-xf29.google.com (mail-qv1-xf29.google.com [IPv6:2607:f8b0:4864:20::f29]) (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 31051C14CEFD for <nfsv4@ietf.org>; Fri, 26 May 2023 05:49:56 -0700 (PDT)
Received: by mail-qv1-xf29.google.com with SMTP id 6a1803df08f44-625f1f31c5fso7981946d6.0 for <nfsv4@ietf.org>; Fri, 26 May 2023 05:49:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1685105395; x=1687697395; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=tqLL0P1cskEyW0zELMOZq2kRjVX+BOYG0FkRVgIAeyU=; b=Cm8yCCFFEDGMY11DN99+wmf79VHx8tWIoLk6yoCd2x8KozynZRDXqiZJCbme2v+XYM YHXJGg5VKyNKGo0sxd1nRd4Tq14z6/XmpYVPPnhqd9pF88SPuC+aHqIDNHGDv9NC52Yq ce03fRpEBEm+2uTEjO4ewW3zT+TiUwMXXDLb2Px4YCi1agmoQU+KycyU/TXEfOoDwtCT OWyrr1ka0YHzQIa2ZE0yhkNLttL385eJJhfgtZMwlYTWLYoIl3CUo7RzS4IDMpwr1X8+ p/bZJ/KOO9bQJeRTBtttBGAE3NXc+bqiNE7vVnmX1zKm2WHzebDsAH3FU2woo3snXyZK O3jg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685105395; x=1687697395; h=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=tqLL0P1cskEyW0zELMOZq2kRjVX+BOYG0FkRVgIAeyU=; b=a0AF5j2dnxb8lSX1fEGL0LjzqY/tdDHtgOLSpQikLznHoctOE2a4tdbHu+SzBCYI10 JEVxXKCs71bjx2+yuaZgut2tbSoMYiaxiKGaJUwurQwYsFK9xyS1mLApLpzdl314J2VO yJo4A64Cm4IwisvGMbSf5eFMTEiCbgf8W/hqWaPDvg6kEtQaRrWb6U7PrraSXp7letdG Kmw8EqZ7hJet8cV9GiliwmLayvcI/5kqmPNOOIlmg+8re9Wb4rSxSJ8EM4cXelO1HS5w 3lTbVNZq2kNxgorH9yZQSBLN5fHTZuA4aI6fKE8vqAkW2RnKlIiBAnFf1fWENXF4o1uV wK5g==
X-Gm-Message-State: AC+VfDy1xfIZ6qlFxDbDCDY/YZBEVxPNMB279i7DvtaegjQtaRSnSCG4 ybBSyAMKdnPD7UMrDTMAGcahHCLFHsZMWG2WHOs=
X-Google-Smtp-Source: ACHHUZ5qlCmNAcNIHBHR8YxhASPk48QfkB0gw/tSkPCVaDUXZAX3i1+Rc4yhE09agAlKiHuDT4Y9zYGauiFH43As5sw=
X-Received: by 2002:ad4:5c6a:0:b0:625:86ed:8aab with SMTP id i10-20020ad45c6a000000b0062586ed8aabmr1032402qvh.14.1685105395228; Fri, 26 May 2023 05:49:55 -0700 (PDT)
MIME-Version: 1.0
References: <c69e80e002d12dbcda9491ad29275022f205cd3e.camel@kernel.org> <D5BD1191-C395-4ACF-BFC8-32A2A1862459@oracle.com> <fd2f216a67e9ca7bde5ff0f063457fac2b434e1c.camel@kernel.org> <14850968-21B9-47DE-A5E1-205141370FB8@oracle.com>
In-Reply-To: <14850968-21B9-47DE-A5E1-205141370FB8@oracle.com>
From: David Noveck <davenoveck@gmail.com>
Date: Fri, 26 May 2023 08:49:43 -0400
Message-ID: <CADaq8jeJM-ZG0ENwjth5OVMtsGFbMrMcYiEjkfD7JyNfP1wXWQ@mail.gmail.com>
To: Chuck Lever III <chuck.lever@oracle.com>
Cc: Jeff Layton <jlayton@kernel.org>, Olga Kornievskaia <kolga@netapp.com>, Trond Myklebust <trondmy@hammerspace.com>, NFSv4 <nfsv4@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000007de4d405fc982c65"
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/EgQ_qUEWnVeJNnEpr_C6wHl3BTA>
Subject: Re: [nfsv4] handling GETATTR vs. fh with outstanding write delegation
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: Fri, 26 May 2023 12:50:00 -0000

On Thu, May 25, 2023, 11:03 AM Chuck Lever III <chuck.lever@oracle.com>
wrote:

[Snip]


> >
> >     • The requested attribute values are returned in the response to
> CB_GETATTR.
> >     • The OPEN_DELEGATE_WRITE delegation is returned.
> >     • The OPEN_DELEGATE_WRITE delegation is revoked.
> >
> > Unless one of the above happens very quickly, one or more NFS4ERR_DELAY
> errors will be returned while a delegation is outstanding.
>
> This is a clear mandate (with a MUST NOT) for the server to
> respond with either a CB_GETATTR or CB_RECALL (or both).
>

Except in the case in which the delegation is returned before the recall is
sent.


> I'm not sure what it means to quickly /revoke/ a delegation.
>

>From the context, it appears that it is being suggested it happens soon
enough to prevent an NFS4ERR_DELAY being sent.  I don't think that is
possible, although rfc8881 does not clearly indicate this.

I thought servers were supposed to give a bit of leeway before
> leaping to revocation.
>

I agree with the non-normative "supposed to" although the existing
treatment of revocation is not very clear about delegation revocation.
Instead, the introduction of revocation indicates:

   - Non-recallable locks are not to be revoked while the lease is active.


   - Layout revocation is pretty much up to the layout type..

Delegation revocation is not explicitly mentioned although there are other
places in the spec that imply that it can happen.

As a practical matter, servers are well advised to recall first and only
revoke if the client is unresponsive, i.e not "very quickly".  The spec
needs to say something like that although coming up with normative language
might not be possible.


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

v2.23.0 | Report a Bug | By Email