Re: [nfsv4] Possibility of adding additional REQUIRED attributes

Christoph Hellwig <hch@lst.de> Wed, 27 March 2024 18:30 UTC

Return-Path: <hch@lst.de>
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 A182BC16A128 for <nfsv4@ietfa.amsl.com>; Wed, 27 Mar 2024 11:30:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.909
X-Spam-Level:
X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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
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 45qPEJrELItw for <nfsv4@ietfa.amsl.com>; Wed, 27 Mar 2024 11:30:43 -0700 (PDT)
Received: from verein.lst.de (verein.lst.de [213.95.11.211]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8DC2C14F6FA for <nfsv4@ietf.org>; Wed, 27 Mar 2024 11:30:42 -0700 (PDT)
Received: by verein.lst.de (Postfix, from userid 2407) id D038168B05; Wed, 27 Mar 2024 19:30:38 +0100 (CET)
Date: Wed, 27 Mar 2024 19:30:38 +0100
From: Christoph Hellwig <hch@lst.de>
To: David Noveck <davenoveck@gmail.com>
Cc: Thomas Haynes <loghyr@hammerspace.com>, NFSv4 <nfsv4@ietf.org>
Message-ID: <20240327183038.GA1481@lst.de>
References: <CADaq8jc0Eaz_ePTu=r44NFKsGtdHOgdy3eFNE1hTgGwr_1Zvqg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CADaq8jc0Eaz_ePTu=r44NFKsGtdHOgdy3eFNE1hTgGwr_1Zvqg@mail.gmail.com>
User-Agent: Mutt/1.5.17 (2007-11-01)
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/3oNPfDEkqeUsRxLYVIZFSS_R1Js>
Subject: Re: [nfsv4] Possibility of adding additional REQUIRED attributes
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: Wed, 27 Mar 2024 18:30:47 -0000

On Mon, Mar 25, 2024 at 01:00:07PM -0400, David Noveck wrote:
>    - fs_charset is very easy for the server to implement

At least for typical layered servers it absolutely is not.  In fact
Linux servers can't implement it in a useful way at the moment.

>    and making it
>    *REQUIRED* avoid the added complexity for the client of dealing with the
>    case of this attribute not being supported.

Any client that actually cares about it would still have to deal
with the lack of it for older minor versions.  Most clients also
couldn't care less about the attribute.

>    - aclsupport raises similar issues even if it is associated with an
> *OPTIONAL
>    *feature.  This is similar to other attributes which provide
> gateways to *OPTIONAL
>    *features, with very simple implementations possible when the
> *OPTIONAL *feature
>    is not supported..

What is the point if the client still needs to handle old minor versions?

>    - fs_layout_type could be made *REQUIRED* with servers not supporting
>    pNFS simply returning a zero-length array.

What is the point of requiring the server to implement an attribute
that does not return anything useful?