IETF Logo Mail Archive

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

Tom Haynes <loghyr@gmail.com> Fri, 26 May 2023 14:18 UTC

Return-Path: <loghyr@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 282B9C15152B for <nfsv4@ietfa.amsl.com>; Fri, 26 May 2023 07:18:45 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 b3r2-3ON5u8Y for <nfsv4@ietfa.amsl.com>; Fri, 26 May 2023 07:18:41 -0700 (PDT)
Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634]) (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 59877C3C9451 for <nfsv4@ietf.org>; Fri, 26 May 2023 07:16:41 -0700 (PDT)
Received: by mail-ej1-x634.google.com with SMTP id a640c23a62f3a-96f5685f902so113254166b.2 for <nfsv4@ietf.org>; Fri, 26 May 2023 07:16:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1685110600; x=1687702600; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=hEtg/PLoCeyHCU1g29G+HLz0a8slW7RF8L99360xm9A=; b=N7/yioNivTLIOU/UMnuZyXMqmsD9RGJ+fzKelQDqx01nZ9TFlB+NzSYWPdELlqPQi3 RGZu2sA5OUQlRYMt1/KuQnscYZbA0J4Lt+y/YkgMJ7gZcMnxTMk57mdEnc3E9xNK826B zUT0MtRnbzmKoq8nWf9yh0x/JvHj27injiYomRpsWvYYIslEgReGgNvFLNUtpZOSYDvB NJG0AAcnNIL/BqzKvUCYL5qgNWYihIVf4T4ZpH4nek7BeDXN2V1Z+mDMmdGBl4BFdkJa lX4dLgwAPUvu5my51Fff8XTDV5RiGxOe/NdYF5d7FyezF1XK6WqrTp83VRaf675ifqtc WLZg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685110600; x=1687702600; 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=hEtg/PLoCeyHCU1g29G+HLz0a8slW7RF8L99360xm9A=; b=GuWnipMMMKP58eMs27QAEuP+Wia9v4fU1NaWfXBRVIjW7Ay9zRutrOekr6Z4C0dp+5 rusq3egw9R/fcKrmwe4vOCMld5Oj6fb28W8pYl50vKwpsn88kqrS4hS19B2keYpAMxsO fd9sbGTtd6p5MrowJK2q6y28u0etrkges2tqyxbFoiUmBvdCc0EQkTZTCCmsVsWDpApW EE2XPbTn11ChALlZAyCyKK7dJLJJRzI/TuhCGlU840gbXeZBDeQOixprpVOxVgL8MBWq 9tBs64RR9Ux5F2gnLQWSEQI1RBIzmYBAt40b6oL61dtVhc0cWUTWNo0VGzyUgd4TUxB+ +6iw==
X-Gm-Message-State: AC+VfDz6Em2XyF9OdMOYSpXriwL8CeRwloe2giO5K0jJSilPR5LP6CS0 tw+CvnZKdhTWaolfwuQpA9+X6WXiYPwNJJ3RF/E=
X-Google-Smtp-Source: ACHHUZ5Y6/Z3CdzNuaojRAAZix8fL233f10GO/lOtCFVfimbY/oa+31+vTx7kQvZN9h4M4y9VtTvqd+a7ES/zheSfrA=
X-Received: by 2002:a17:907:1b1a:b0:96f:678:d2fc with SMTP id mp26-20020a1709071b1a00b0096f0678d2fcmr1898324ejc.22.1685110599295; Fri, 26 May 2023 07:16:39 -0700 (PDT)
MIME-Version: 1.0
References: <c69e80e002d12dbcda9491ad29275022f205cd3e.camel@kernel.org> <D5BD1191-C395-4ACF-BFC8-32A2A1862459@oracle.com> <fd2f216a67e9ca7bde5ff0f063457fac2b434e1c.camel@kernel.org> <CADaq8jcmpOfUndjaRHY_Xmf6qpXaHD_Xr4fR-6Wz6i4v-qjHTw@mail.gmail.com> <1D0181F8-A7A5-4D26-99CA-5C3EEB4CC8DF@oracle.com>
In-Reply-To: <1D0181F8-A7A5-4D26-99CA-5C3EEB4CC8DF@oracle.com>
From: Tom Haynes <loghyr@gmail.com>
Date: Fri, 26 May 2023 15:16:27 +0100
Message-ID: <CAMa=BDryRhqEmpMR=VZ9RUtMXmU1dVe=gPFcFnYHdKewuSFrSQ@mail.gmail.com>
To: Chuck Lever III <chuck.lever@oracle.com>
Cc: David Noveck <davenoveck@gmail.com>, Jeff Layton <jlayton@kernel.org>, Olga Kornievskaia <kolga@netapp.com>, Trond Myklebust <trondmy@hammerspace.com>, NFSv4 <nfsv4@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ada5b905fc9962d7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/2Os8D5c2E9fFJu9GcUZLVYco5PM>
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 14:18:45 -0000

Hammerspace also does CB_GETATTR



On Fri, May 26, 2023, 14:44 Chuck Lever III <chuck.lever@oracle.com> wrote:

>
> > On May 26, 2023, at 6:14 AM, David Noveck <davenoveck@gmail.com> wrote:
> >
> >> On Thu, May 25, 2023, 6:38 PM Jeff Layton <jlayton@kernel.org> wrote:
> >>> On Thu, 2023-05-25 at 13:45 +0000, Chuck Lever III wrote:
> >>>
> >>>> On May 25, 2023, at 7:46 AM, Jeff Layton <jlayton@kernel.org> wrote:
> >>>> The filer simply reports the info it has in response to a GETATTR
> >>>> without using CB_GETATTR and without recalling a delegation.
> >>>
> >>> As a data point, the Solaris server implementation also does not
> >>> implement CB_GETATTR, nor does it send a CB_RECALL in this case.
> >>
> >> Good to know, thanks.
> >
> > So we have two servers that behave this way.  From the tone of your
> previous message, we may have a third under development.
>
> We are actively debating whether CB_GETATTR is worth implementing. It
> appears to be something that could be added in a later phase of
> implementing write delegation support.
>
> Otherwise, since a mandate to "ensure that a delegation is no longer
> present before returning a GETATTR response" has been found in RFC 8881
> S. 18.7.4, IMO we are obligated to add at least that behavior to the
> Linux NFS server.
>
>
> > Also, it would be nice to know of any servers that do follow rfc8881 in
> this regard.
>
> Frank Filz indicated to us that NFS/Ganesha implements CB_GETATTR.
>
>
> --
> Chuck Lever
>
>
> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4
>

v2.23.0 | Report a Bug | By Email