Re: [nfsv4] proposed change for RFC 8881 bis
Rick Macklem <rick.macklem@gmail.com> Thu, 21 March 2024 20:57 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 E49FEC1D6FA9 for <nfsv4@ietfa.amsl.com>; Thu, 21 Mar 2024 13:57:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.108
X-Spam-Level:
X-Spam-Status: No, score=-7.108 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, T_SCC_BODY_TEXT_LINE=-0.01] 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 bWKS1il8QQVj for <nfsv4@ietfa.amsl.com>; Thu, 21 Mar 2024 13:57:25 -0700 (PDT)
Received: from mail-pj1-x1030.google.com (mail-pj1-x1030.google.com [IPv6:2607:f8b0:4864:20::1030]) (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 CDA8AC14F6B0 for <nfsv4@ietf.org>; Thu, 21 Mar 2024 13:57:25 -0700 (PDT)
Received: by mail-pj1-x1030.google.com with SMTP id 98e67ed59e1d1-29f6f8614c8so1104484a91.0 for <nfsv4@ietf.org>; Thu, 21 Mar 2024 13:57:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711054645; x=1711659445; 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=Zw8vxK6YOYAUjGI2PRNvjdgBiMYp1AhOT6DRP0NEQ1Y=; b=mhK+vYsLe1fsNeF/hFjn2LAWI+nlw2njBhE1vTzHWr/KPryBh8ZpJA8Tu3OGCYuo0F ecxMHZjnDCcYZJjF14fpixMn8UtEnWN09vYUIryYFS8G1UGCHoglhlTAC5NqYj++gZa8 v72FMfb+Eo5yhFTEf6eg1gD7mU0bAoaUHq9O0ZSbz6GOrKRapzRyHaYdEi0bJ6j3Ou9U Tq1OqfhiqGAY4c4e/DwEGswxsu6lEgJr9AOJXGt//BAHrSgfzRVe50KNaKoknvy4Ca6A 3aDnbutJcv2Xcuh8AENhHCcWOrnmc2WmuvTXfG4fjowPJiPeRuv3pEtl0bxhNVtoC8tO UqkQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711054645; x=1711659445; 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=Zw8vxK6YOYAUjGI2PRNvjdgBiMYp1AhOT6DRP0NEQ1Y=; b=fsboNn8fgiGc1FRpkZxb1hmubUs75pQPVvIKY7aIsDm42ce1iBM7oF5J3KR+xyi0+n uPGUL2rDjR07kpS8vpAs43ZRGHskwu9KI8KblKDCPZPIuXKPUD2mKjAKYiyOQRD35wyb mBJCyw8HoRG/8Q7oxCqKgtb7jDx/rN2ogxmZ9Xu7QLnAELNLyNBUFm/bxp4WQZockrZv AYbd8JpWecK/KqnA32tEO/qsfeKswffJdJWmjLZnPR2zajvJSfRs2BsZF5Gp3uwzIe05 YJ8ZMmmmSR68fXEFMSQyG+dO+upIB9lA/1j+sLT2VcQ6IbyoH3a6vVHcbUEEMHl81RH2 HcVg==
X-Gm-Message-State: AOJu0Yxu1TkPwapGB8KTixaFJj7SrrystGb5C4KLtBOf/JGWjXs1qio6 Muyh7ZcjuMCAuWX78VpeX/IzgSiZ/sX4XdCy6RMUACfxU9wr6J0T512+0CmWrAxALL5j3gsYPg5 7rb4Lbz3MQNeFdscPBtGJwnuRoA==
X-Google-Smtp-Source: AGHT+IHaTthSunwo/mh+Om1a5dufTLMuPgH5iLydi0OmKGma2/mnblw6jLqUGIpkUVP8EpaTpXjDn9NgOXFMtdpMiWM=
X-Received: by 2002:a17:90b:33c8:b0:29c:791d:b5d5 with SMTP id lk8-20020a17090b33c800b0029c791db5d5mr642796pjb.34.1711054645165; Thu, 21 Mar 2024 13:57:25 -0700 (PDT)
MIME-Version: 1.0
References: <bc35d96b03e27bc032ed9e08101c5b334728a319.camel@poochiereds.net>
In-Reply-To: <bc35d96b03e27bc032ed9e08101c5b334728a319.camel@poochiereds.net>
From: Rick Macklem <rick.macklem@gmail.com>
Date: Thu, 21 Mar 2024 13:57:09 -0700
Message-ID: <CAM5tNy4p7M+OC6TVzbrpa0qpUDHJW_95YJ-EQGjhs50hWhYBdQ@mail.gmail.com>
To: Jeff Layton <jlayton@poochiereds.net>
Cc: NFSv4 <nfsv4@ietf.org>, Chuck Lever <chuck.lever@oracle.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/Ayo19Vs-C6_W9JP_G743LeVp6zA>
Subject: Re: [nfsv4] proposed change for RFC 8881 bis
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: Thu, 21 Mar 2024 20:57:28 -0000
Sounds fine to me, rick On Thu, Mar 21, 2024 at 10:39 AM Jeff Layton <jlayton@poochiereds.net> wrote: > > I've been working on a draft implementation of directory delegations for > the Linux client and server. RFC 8881 says in section 18.39.3: > > "The server may refuse to grant the delegation. In that case, the server > will return NFS4ERR_DIRDELEG_UNAVAIL." > > ...and later: > > "If the server does not wish to honor the "want" or is not able to do > so, it returns the error NFS4ERR_DIRDELEG_UNAVAIL." > > This behavior is straightforward to implement, but it seems sub-optimal > to have the server return a hard error in these situations, since it > will cause compound processing to abort. Acquiring a delegation is an > optimization, and failure to get one ought not be fatal. > > Could we change it so that in either situation, we can have the server > optionally return NFS4_OK + GDD4_UNAVAIL instead of > NFS4ERR_DIRDELEG_UNAVAIL? That would allow later compound operations to > proceed, and would be less expensive than having to redrive a whole RPC. > > Thoughts? > > I'm happy to draft up a proposed change if someone can point me in the > right direction. > > Thanks, > -- > Jeff Layton <jlayton@poochiereds.net>
- [nfsv4] proposed change for RFC 8881 bis Jeff Layton
- Re: [nfsv4] proposed change for RFC 8881 bis Rick Macklem
- Re: [nfsv4] proposed change for RFC 8881 bis David Noveck