Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
From:   Rick Macklem <rick.macklem@gmail.com>
Date:   Fri, 4 Aug 2023 15:18:52 -0700
Message-ID: <CAM5tNy4d02dOyWsVk7Y-nFEyGjE=eo4nJgrap3M5DebDJz9ehw@mail.gmail.com>
Subject: RFC: new attributes
To:     Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Cc:     David Noveck <davenoveck@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

Hi,

I wrote an IETF draft proposing a few new attributes for NFSv4.2.
Since there did not seem to be interest in them, I just
let the draft expire.  However, David Noveck pinged
me w.r.t. it, so I thought I'd ask here about it.

All the attributes are meant to be "read only, per server file system":
supported_ops - A bitmap of the operations supported.
     The motivation was that NFS4ERR_NOTSUPP is supposed to
      be "per server", although the rumour was that the Linux knfsd
      uses it "per server file system".
dir_cookie_rising - Only useful for directory delegations, which no
      one seems to be implementing.
seek_granularity - The smallest size of unallocated region reported
      be the Seek operation.  FreeBSD has a pathconf(2) variable called
      _PC_MIN_HOLE_SIZE that an application can use to decide if
      lseek(SEEK_DATA/SEEK_HOLE) is useful.
mandatory_br_locks - Byte range locks are mandatory.  No one
      seems to be implementing these, but a client needs to know
      that mandatory locking is being enforced so that it can cache
      data correctly.
max_xattr_len - Allows the client to avoid attempting to Setxattr an
     attribute that is larger than the server file system supports.

So, does the Linux folk think any of these are useful enough to implement?
If not, I do not see any reason to pursue this further.

Thanks for any comments, rick