Message-ID: <20260119-kanufahren-meerjungfrau-775048806544@brauner>
Date: Mon, 19 Jan 2026 10:27:11 +0100
From: Christian Brauner <brauner@...nel.org>
To: NeilBrown <neil@...wn.name>
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, 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.

Powered by blists - more mailing lists