IETF Logo Mail Archive

Re: [nfsv4] Can NFSv4.2 operations be optional on a per server file system basis?

Thomas Haynes <loghyr@gmail.com> Sun, 10 October 2021 18:16 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 3476A3A0BDB for <nfsv4@ietfa.amsl.com>; Sun, 10 Oct 2021 11:16:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e7ceqcf7tyCH for <nfsv4@ietfa.amsl.com>; Sun, 10 Oct 2021 11:16:14 -0700 (PDT)
Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0:4864:20::531]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B20993A0BDC for <nfsv4@ietf.org>; Sun, 10 Oct 2021 11:16:14 -0700 (PDT)
Received: by mail-pg1-x531.google.com with SMTP id v11so8655088pgb.8 for <nfsv4@ietf.org>; Sun, 10 Oct 2021 11:16:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=e2dNyWEtukfSh/lYFyLtZLINvHahIVq0O+CQY5JkBIA=; b=RT/Nb8jOfqfNuMmghcOeevp/PeHo8+DTRWe9FzV/PPqDxLLlvBA6kqjSKgDwhfJDtK Wvz/kQnQxn8OiUAmQLKm5fZ1f0TXPSHo5nEvYDZhKVREAA9kAuPkhRXQCat5rdWvz082 a9Gxmn4sBw0BN7itoybQp7cDl5BfNvtsz6B9nR9yJGi3uag7M+dDUSTjV2Fu55z+bto/ 2vMCmfasB41qnokUyjw6ycPUY9mgu95kctalAMTa8894QJ+0Fi1LG2Ozh7l6FcfepbYg WNVLv9Qs9KquWBUgdI6ID7My3X3Se7i/ijS2VIJZIROY3MSUAaEnkz45NBz0WmAJya8J rWEg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=e2dNyWEtukfSh/lYFyLtZLINvHahIVq0O+CQY5JkBIA=; b=hPyD4NacFh8CtMLx+77mjUrqBvnban+2C0RgsXkTljsR+ZUY0kXAAP0t2R9vMJdwN2 Kn02ml0alKdncxbCjafrZmbwAb/v3v7qcVhETcWmBF0peZoIKrMqq3A7ehG76YSM+EPf 2cKSo6RsI63tBEPPLAYidWMpszyLejTcQUjrB6CqqDYOwLsuThR0jOa61zDEJ/4MyTzl wGz760Sxem2tIt3L1VsMgMIAOrImhY4I3ruKQ21rx+qKuSoJKkItW3s3UEjnpPjqcXZm T+hR/jAfD8nabsPfyqhF+paMRJhGmvA3qY/Spu/6NxEm6Himoax54cMeC1ltQ5PkTQWf MS/A==
X-Gm-Message-State: AOAM532qM60D5GmOJNNT/mDdhitcPlvku6IK4kaOPxL9HeGWvnQg4kIg Yr2gu+LHzyJwBFlFjtdcuMI=
X-Google-Smtp-Source: ABdhPJwfPI33JT0YgH5eLY0TMOtyDQ2WAgMr4YtmOTaeSap6TbUXlESPNSJ3921ysF3fV7otz+lDkA==
X-Received: by 2002:a05:6a00:1506:b0:44c:d702:4e12 with SMTP id q6-20020a056a00150600b0044cd7024e12mr16012616pfu.54.1633889773894; Sun, 10 Oct 2021 11:16:13 -0700 (PDT)
Received: from smtpclient.apple (c-69-181-67-218.hsd1.ca.comcast.net. [69.181.67.218]) by smtp.gmail.com with ESMTPSA id w125sm5211317pfc.66.2021.10.10.11.16.13 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 10 Oct 2021 11:16:13 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
From: Thomas Haynes <loghyr@gmail.com>
In-Reply-To: <YQXPR0101MB0968D58C78D6E9ACBF7B8A3FDDB49@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM>
Date: Sun, 10 Oct 2021 11:16:12 -0700
Cc: "nfsv4@ietf.org" <nfsv4@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <683B4D58-BFDF-465D-9E77-607819354EAA@gmail.com>
References: <YQXPR0101MB0968D58C78D6E9ACBF7B8A3FDDB49@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM>
To: Rick Macklem <rmacklem@uoguelph.ca>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/R_KiLj0SzffvJnyGuIcTgzooeEk>
Subject: Re: [nfsv4] Can NFSv4.2 operations be optional on a per server file system basis?
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.29
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, 10 Oct 2021 18:16:19 -0000


> On Oct 10, 2021, at 7:07 AM, Rick Macklem <rmacklem@uoguelph.ca> wrote:
> 
> Hi,
> 
> I'm guessing the answer is "no", but I figured I'd ask just to make sure,
> since RFC7862 states that operations are optional, but does not clarify
> beyond that.
> 
> So, if an NFSv4.2 server exports two file systems, where one of them can
> perform the operation and the other cannot, is the server allowed to
> reply NFS4ERR_NOTSUPP for the operation when attempted on files
> in the file system that cannot perform the operation?
> 
> Thanks, rick
> ps: In FreeBSD, UFS can do Allocate, but ZFS cannot.
> 
> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4


Hi Rick,

The answer is “no”.

But the question is very interesting. NFS4ERR_INVAL might be the most appropriate of the allowed errors, but pretty sure you do not want to be returning that.

Of the not allowed errors, I think that NFS4ERR_OFFLOAD_DENIED is closest to what you want. You actually want an NFS4ERR_ALLOCATE_DENIED. It would mean that ALLOCATE was supported, but not allowed for the given file.

And I have no clue how easy it would be to drive that into the standard’s body any more. :-)

Tom

v2.23.0 | Report a Bug | By Email