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;
Message-ID: <a486f239b361a6f03cf40c3762876e206c5dbfd8.camel@kernel.org>
Subject: Re: [LSF/MM/BPF TOPIC] BoF for nfsd
From:   Jeff Layton <jlayton@kernel.org>
To:     Christian Brauner <brauner@kernel.org>,
        Chuck Lever III <chuck.lever@oracle.com>
Cc:     "lsf-pc@lists.linux-foundation.org" 
        <lsf-pc@lists.linux-foundation.org>,
        linux-fsdevel <linux-fsdevel@vger.kernel.org>,
        Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Date:   Thu, 13 Apr 2023 09:09:14 -0400
In-Reply-To: <20230413-perspektive-glasur-6e2685229a95@brauner>
References: <FF0202C3-7500-4BB3-914B-DBAA3E0EA3D7@oracle.com>
         <20230413-perspektive-glasur-6e2685229a95@brauner>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.46.4 (3.46.4-1.fc37) 
MIME-Version: 1.0
Precedence: bulk

On Thu, 2023-04-13 at 11:33 +0200, Christian Brauner wrote:
> On Wed, Apr 12, 2023 at 06:27:07PM +0000, Chuck Lever III wrote:
> > I'd like to request some time for those interested specifically
> > in NFSD to gather and discuss some topics. Not a network file
> > system free-for-all, but specifically for NFSD, because there
> > is a long list of potential topics:
> >=20
> >     =E2=80=A2 Progress on using iomap for NFSD READ/READ_PLUS (anna)
> >     =E2=80=A2 Replacing nfsd_splice_actor (all)
> >     =E2=80=A2 Transition from page arrays to bvecs (dhowells, hch)
> >     =E2=80=A2 tmpfs directory cookie stability (cel)
> >     =E2=80=A2 timestamp resolution and i_version (jlayton)
>=20
> I'd attend this one.
>=20

I wonder if we ought to propose a separate FS track spot for this? I
sort of expect some lively discussion, and this may be of more interest
than just nfsd folks.

> >     =E2=80=A2 GSS Kerberos futures (dhowells)
> >     =E2=80=A2 NFS/NFSD CI (jlayton)
> >     =E2=80=A2 NFSD POSIX to NFSv4 ACL translation - writing down the ru=
les (all)
>=20
> I have some experience dealing with ACLs so I'm happy to attend just in
> case I may be useful.

That would be helpful! I'll note that there was a draft RFC for this
many years ago, but it expired:

  =C2=A0https://datatracker.ietf.org/doc/html/draft-ietf-nfsv4-acl-mapping-=
05

I think most of the rules are laid out there, but there are some areas
where things just don't work right.

A more radical idea:

I wonder if we could get any traction at the IETF on a POSIX ACL
extension for NFSv4? Basically, we could resurrect the old v3 nfsacl
protocol as new operations for v4, and allow the client and server to
negotiate on using them.

Given that almost all the clients and servers in operation on the planet
have to translate these, it makes some sense to avoid the translation
when we can.

--=20
Jeff Layton <jlayton@kernel.org>