Message-id: <176885553525.16766.291581709413217562@noble.neil.brown.name>
Date: Tue, 20 Jan 2026 07:45:35 +1100
From: NeilBrown <neilb@...mail.net>
To: "Christian Brauner" <brauner@...nel.org>
Cc: "Christoph Hellwig" <hch@...radead.org>,
 "Jeff Layton" <jlayton@...nel.org>,
 "Amir Goldstein" <amir73il@...il.com>,
 "Alexander Viro" <viro@...iv.linux.org.uk>,
 "Chuck Lever" <chuck.lever@...cle.com>,
 "Olga Kornievskaia" <okorniev@...hat.com>,
 "Dai Ngo" <Dai.Ngo@...cle.com>, "Tom Talpey" <tom@...pey.com>,
 "Hugh Dickins" <hughd@...gle.com>,
 "Baolin Wang" <baolin.wang@...ux.alibaba.com>,
 "Andrew Morton" <akpm@...ux-foundation.org>,
 "Theodore Ts'o" <tytso@....edu>,
 "Andreas Dilger" <adilger.kernel@...ger.ca>, "Jan Kara" <jack@...e.com>,
 "Gao Xiang" <xiang@...nel.org>, "Chao Yu" <chao@...nel.org>,
 "Yue Hu" <zbestahu@...il.com>, "Jeffle Xu" <jefflexu@...ux.alibaba.com>,
 "Sandeep Dhavale" <dhavale@...gle.com>,
 "Hongbo Li" <lihongbo22@...wei.com>, "Chunhai Guo" <guochunhai@...o.com>,
 "Carlos Maiolino" <cem@...nel.org>, "Ilya Dryomov" <idryomov@...il.com>,
 "Alex Markuze" <amarkuze@...hat.com>,
 "Viacheslav Dubeyko" <slava@...eyko.com>, "Chris Mason" <clm@...com>,
 "David Sterba" <dsterba@...e.com>,
 "Luis de Bethencourt" <luisbg@...nel.org>,
 "Salah Triki" <salah.triki@...il.com>,
 "Phillip Lougher" <phillip@...ashfs.org.uk>,
 "Steve French" <sfrench@...ba.org>, "Paulo Alcantara" <pc@...guebit.org>,
 "Ronnie Sahlberg" <ronniesahlberg@...il.com>,
 "Shyam Prasad N" <sprasad@...rosoft.com>,
 "Bharath SM" <bharathsm@...rosoft.com>,
 "Miklos Szeredi" <miklos@...redi.hu>,
 "Mike Marshall" <hubcap@...ibond.com>,
 "Martin Brandenburg" <martin@...ibond.com>,
 "Mark Fasheh" <mark@...heh.com>, "Joel Becker" <jlbec@...lplan.org>,
 "Joseph Qi" <joseph.qi@...ux.alibaba.com>,
 "Konstantin Komarov" <almaz.alexandrovich@...agon-software.com>,
 "Ryusuke Konishi" <konishi.ryusuke@...il.com>,
 "Trond Myklebust" <trondmy@...nel.org>,
 "Anna Schumaker" <anna@...nel.org>, "Dave Kleikamp" <shaggy@...nel.org>,
 "David Woodhouse" <dwmw2@...radead.org>,
 "Richard Weinberger" <richard@....at>, "Jan Kara" <jack@...e.cz>,
 "Andreas Gruenbacher" <agruenba@...hat.com>,
 "OGAWA Hirofumi" <hirofumi@...l.parknet.co.jp>,
 "Jaegeuk Kim" <jaegeuk@...nel.org>, linux-nfs@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
 linux-mm@...ck.org, linux-ext4@...r.kernel.org,
 linux-erofs@...ts.ozlabs.org, linux-xfs@...r.kernel.org,
 ceph-devel@...r.kernel.org, linux-btrfs@...r.kernel.org,
 linux-cifs@...r.kernel.org, linux-unionfs@...r.kernel.org,
 devel@...ts.orangefs.org, ocfs2-devel@...ts.linux.dev,
 ntfs3@...ts.linux.dev, linux-nilfs@...r.kernel.org,
 jfs-discussion@...ts.sourceforge.net, linux-mtd@...ts.infradead.org,
 gfs2@...ts.linux.dev, linux-f2fs-devel@...ts.sourceforge.net
Subject: Re: [PATCH 00/29] fs: require filesystems to explicitly opt-in to
 nfsd export support

On Mon, 19 Jan 2026, Christian Brauner wrote:
> On Mon, Jan 19, 2026 at 06:22:42PM +1100, NeilBrown wrote:
> > On Mon, 19 Jan 2026, Christoph Hellwig wrote:
> > > On Mon, Jan 19, 2026 at 10:23:13AM +1100, NeilBrown wrote:
> > > > > This was Chuck's suggested name. His point was that STABLE means that
> > > > > the FH's don't change during the lifetime of the file.
> > > > > 
> > > > > I don't much care about the flag name, so if everyone likes PERSISTENT
> > > > > better I'll roll with that.
> > > > 
> > > > I don't like PERSISTENT.
> > > > I'd rather call a spade a spade.
> > > > 
> > > >   EXPORT_OP_SUPPORTS_NFS_EXPORT
> > > > or
> > > >   EXPORT_OP_NOT_NFS_COMPATIBLE
> > > > 
> > > > The issue here is NFS export and indirection doesn't bring any benefits.
> > > 
> > > No, it absolutely is not.  And the whole concept of calling something
> > > after the initial or main use is a recipe for a mess.
> > 
> > We are calling it for it's only use.  If there was ever another use, we
> > could change the name if that made sense.  It is not a public name, it
> > is easy to change.
> > 
> > > 
> > > Pick a name that conveys what the flag is about, and document those
> > > semantics well.  This flag is about the fact that for a given file,
> > > as long as that file exists in the file system the handle is stable.
> > > Both stable and persistent are suitable for that, nfs is everything
> > > but.
> > 
> > My understanding is that kernfs would not get the flag.
> > kernfs filehandles do not change as long as the file exist.
> > But this is not sufficient for the files to be usefully exported.
> > 
> > I suspect kernfs does re-use filehandles relatively soon after the
> > file/object has been destroyed.  Maybe that is the real problem here:
> > filehandle reuse, not filehandle stability.
> > 
> > Jeff: could you please give details (and preserve them in future cover
> > letters) of which filesystems are known to have problems and what
> > exactly those problems are?
> > 
> > > 
> > > Remember nfs also support volatile file handles, and other applications
> > > might rely on this (I know of quite a few user space applications that
> > > do, but they are kinda hardwired to xfs anyway).
> > 
> > The NFS protocol supports volatile file handles.  knfsd does not.
> > So maybe
> >   EXPORT_OP_NOT_NFSD_COMPATIBLE
> > might be better.  or EXPORT_OP_NOT_LINUX_NFSD_COMPATIBLE.
> > (I prefer opt-out rather than opt-in because nfsd export was the
> > original purpose of export_operations, but it isn't something
> > I would fight for)
> 
> I prefer one of the variants you proposed here but I don't particularly
> care. It's not a hill worth dying on. So if Christoph insists on the
> other name then I say let's just go with it.
> 

This sounds like you are recommending that we give in to bullying.
I would rather the decision be made based on the facts of the case, not
the opinions that are stated most bluntly.

I actually think that what Christoph wants is actually quite different
from what Jeff wants, and maybe two flags are needed.  But I don't yet
have a clear understanding of what Christoph wants, so I cannot be sure.

NeilBrown

Powered by blists - more mailing lists