From: Christian Brauner <brauner@kernel.org>
To: NeilBrown <neil@brown.name>
Cc: Christoph Hellwig <hch@infradead.org>,
Jeff Layton <jlayton@kernel.org>,
Amir Goldstein <amir73il@gmail.com>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Chuck Lever <chuck.lever@oracle.com>,
Olga Kornievskaia <okorniev@redhat.com>,
Dai Ngo <Dai.Ngo@oracle.com>, Tom Talpey <tom@talpey.com>,
Hugh Dickins <hughd@google.com>,
Baolin Wang <baolin.wang@linux.alibaba.com>,
Andrew Morton <akpm@linux-foundation.org>,
Theodore Ts'o <tytso@mit.edu>,
Andreas Dilger <adilger.kernel@dilger.ca>,
Jan Kara <jack@suse.com>, Gao Xiang <xiang@kernel.org>,
Chao Yu <chao@kernel.org>, Yue Hu <zbestahu@gmail.com>,
Jeffle Xu <jefflexu@linux.alibaba.com>,
Sandeep Dhavale <dhavale@google.com>,
Hongbo Li <lihongbo22@huawei.com>,
Chunhai Guo <guochunhai@vivo.com>,
Carlos Maiolino <cem@kernel.org>,
Ilya Dryomov <idryomov@gmail.com>,
Alex Markuze <amarkuze@redhat.com>,
Viacheslav Dubeyko <slava@dubeyko.com>, Chris Mason <clm@fb.com>,
David Sterba <dsterba@suse.com>,
Luis de Bethencourt <luisbg@kernel.org>,
Salah Triki <salah.triki@gmail.com>,
Phillip Lougher <phillip@squashfs.org.uk>,
Steve French <sfrench@samba.org>,
Paulo Alcantara <pc@manguebit.org>,
Ronnie Sahlberg <ronniesahlberg@gmail.com>,
Shyam Prasad N <sprasad@microsoft.com>,
Bharath SM <bharathsm@microsoft.com>,
Miklos Szeredi <miklos@szeredi.hu>,
Mike Marshall <hubcap@omnibond.com>,
Martin Brandenburg <martin@omnibond.com>,
Mark Fasheh <mark@fasheh.com>, Joel Becker <jlbec@evilplan.org>,
Joseph Qi <joseph.qi@linux.alibaba.com>,
Konstantin Komarov <almaz.alexandrovich@paragon-software.com>,
Ryusuke Konishi <konishi.ryusuke@gmail.com>,
Trond Myklebust <trondmy@kernel.org>,
Anna Schumaker <anna@kernel.org>,
Dave Kleikamp <shaggy@kernel.org>,
David Woodhouse <dwmw2@infradead.org>,
Richard Weinberger <richard@nod.at>, Jan Kara <jack@suse.cz>,
Andreas Gruenbacher <agruenba@redhat.com>,
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>,
Jaegeuk Kim <jaegeuk@kernel.org>,
linux-nfs@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
linux-ext4@vger.kernel.org, linux-erofs@lists.ozlabs.org,
linux-xfs@vger.kernel.org, ceph-devel@vger.kernel.org,
linux-btrfs@vger.kernel.org, linux-cifs@vger.kernel.org,
linux-unionfs@vger.kernel.org, devel@lists.orangefs.org,
ocfs2-devel@lists.linux.dev, ntfs3@lists.linux.dev,
linux-nilfs@vger.kernel.org,
jfs-discussion@lists.sourceforge.net,
linux-mtd@lists.infradead.org, gfs2@lists.linux.dev,
linux-f2fs-devel@lists.sourceforge.net
Subject: Re: [PATCH 00/29] fs: require filesystems to explicitly opt-in to nfsd export support
Date: Tue, 20 Jan 2026 11:31:54 +0100 [thread overview]
Message-ID: <20260120-hacken-revision-88209121ac2c@brauner> (raw)
In-Reply-To: <176890211061.16766.16354247063052030403@noble.neil.brown.name>
On Tue, Jan 20, 2026 at 08:41:50PM +1100, NeilBrown wrote:
> On Tue, 20 Jan 2026, Christian Brauner wrote:
> > On Tue, Jan 20, 2026 at 07:45:35AM +1100, NeilBrown wrote:
> > > 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.
> >
> > I've tried to indirectly ask whether you would be willing to compromise
> > here or whether you want to insist on your alternative name. Apparently
> > that didn't come through.
>
> This would be the "not a hill worthy dying on" part of your statement.
> I think I see that implication now.
> But no, I don't think compromise is relevant. I think the problem
> statement as originally given by Jeff is misleading, and people have
> been misled to an incorrect name.
>
> >
> > I'm unclear what your goal is in suggesting that I recommend "we" give
> > into bullying. All it achieved was to further derail this thread.
> >
>
> The "We" is the same as the "us" in "let's just go with it".
>
>
> > I also think it's not very helpful at v6 of the discussion to start
> > figuring out what the actual key rift between Jeff's and Christoph's
> > position is. If you've figured it out and gotten an agreement and this
> > is already in, send a follow-up series.
>
> v6? v2 was posted today. But maybe you are referring the some other
> precursors.
>
> The introductory statement in v2 is
>
> This patchset adds a flag that indicates whether the filesystem supports
> stable filehandles (i.e. that they don't change over the life of the
> file). It then makes any filesystem that doesn't set that flag
> ineligible for nfsd export.
>
> Nobody else questioned the validity of that. I do.
> No evidence was given that there are *any* filesystems that don't
> support stable filehandles. The only filesystem mentioned is cgroups
> and it DOES provide stable filehandles.
Oh yes we did. And this is a merry-go-round.
It is very much fine for a filesystems to support file handles without
wanting to support exporting via NFS. That is especially true for
in-kernel pseudo filesystems.
As I've said before multiple times I want a way to allow filesystems
such as pidfs and nsfs to use file handles without supporting export.
Whatever that fscking flag is called at this point I fundamentally don't
care. And we are reliving the same arguments over and over.
I will _hard NAK_ anything that starts mandating that export of
filesystems must be allowed simply because their file handles fit export
criteria. I do not care whether pidfs or nsfs file handles fit the bill.
They will not be exported.
next prev parent reply other threads:[~2026-01-20 10:32 UTC|newest]
Thread overview: 92+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-15 17:47 Jeff Layton
2026-01-15 17:47 ` [PATCH 01/29] exportfs: add new EXPORT_OP_STABLE_HANDLES flag Jeff Layton
2026-01-16 10:45 ` Jan Kara
2026-01-15 17:47 ` [PATCH 02/29] tmpfs: add EXPORT_OP_STABLE_HANDLES flag to export operations Jeff Layton
2026-01-16 10:47 ` Jan Kara
2026-01-15 17:47 ` [PATCH 03/29] ext4: " Jeff Layton
2026-01-16 2:22 ` Theodore Tso
2026-01-16 10:46 ` Jan Kara
2026-01-15 17:47 ` [PATCH 04/29] ext2: " Jeff Layton
2026-01-16 10:46 ` Jan Kara
2026-01-15 17:47 ` [PATCH 05/29] erofs: " Jeff Layton
2026-01-15 17:47 ` [PATCH 06/29] efs: " Jeff Layton
2026-01-15 17:47 ` [PATCH 07/29] xfs: " Jeff Layton
2026-01-15 17:47 ` [PATCH 08/29] ceph: " Jeff Layton
2026-01-15 19:16 ` Viacheslav Dubeyko
2026-01-15 17:47 ` [PATCH 09/29] btrfs: " Jeff Layton
2026-01-15 17:47 ` [PATCH 10/29] befs: " Jeff Layton
2026-01-15 17:47 ` [PATCH 11/29] ufs: " Jeff Layton
2026-01-15 17:47 ` [PATCH 12/29] udf: " Jeff Layton
2026-01-16 10:47 ` Jan Kara
2026-01-15 17:47 ` [PATCH 13/29] affs: " Jeff Layton
2026-01-15 17:47 ` [PATCH 14/29] squashfs: " Jeff Layton
2026-01-15 17:47 ` [PATCH 15/29] smb/client: " Jeff Layton
2026-01-15 19:26 ` Amir Goldstein
2026-01-15 17:47 ` [PATCH 16/29] ovl: " Jeff Layton
2026-01-15 18:21 ` Amir Goldstein
2026-01-15 17:47 ` [PATCH 17/29] orangefs: " Jeff Layton
2026-01-15 17:47 ` [PATCH 18/29] ocfs2: " Jeff Layton
2026-01-16 10:47 ` Jan Kara
2026-01-15 17:47 ` [PATCH 19/29] ntfs3: " Jeff Layton
2026-01-15 17:47 ` [PATCH 20/29] nilfs2: " Jeff Layton
2026-01-19 8:39 ` Ryusuke Konishi
2026-01-15 17:47 ` [PATCH 21/29] nfs: " Jeff Layton
2026-01-15 17:47 ` [PATCH 22/29] jfs: " Jeff Layton
2026-01-15 22:09 ` Dave Kleikamp
2026-01-15 17:47 ` [PATCH 23/29] jffs2: " Jeff Layton
2026-01-18 15:36 ` Richard Weinberger
2026-01-15 17:47 ` [PATCH 24/29] isofs: " Jeff Layton
2026-01-16 10:48 ` Jan Kara
2026-01-15 17:47 ` [PATCH 25/29] gfs2: " Jeff Layton
2026-01-15 17:47 ` [PATCH 26/29] fuse: " Jeff Layton
2026-01-15 18:54 ` Amir Goldstein
2026-01-15 19:46 ` Jeff Layton
2026-01-15 17:47 ` [PATCH 27/29] fat: " Jeff Layton
2026-01-15 17:47 ` [PATCH 28/29] f2fs: " Jeff Layton
2026-01-15 17:48 ` [PATCH 29/29] nfsd: only allow filesystems that set EXPORT_OP_STABLE_HANDLES Jeff Layton
2026-01-15 19:23 ` Amir Goldstein
2026-01-16 12:36 ` Jeff Layton
2026-01-16 14:46 ` Amir Goldstein
2026-01-16 15:13 ` Jeff Layton
2026-01-15 18:17 ` [PATCH 00/29] fs: require filesystems to explicitly opt-in to nfsd export support Amir Goldstein
2026-01-15 18:29 ` Jeff Layton
2026-01-18 23:23 ` NeilBrown
2026-01-19 6:41 ` Christoph Hellwig
2026-01-19 7:22 ` NeilBrown
2026-01-19 7:25 ` Christoph Hellwig
2026-01-19 9:27 ` Christian Brauner
2026-01-19 20:45 ` NeilBrown
2026-01-20 7:38 ` Christoph Hellwig
2026-01-20 9:27 ` NeilBrown
2026-01-20 10:34 ` Christian Brauner
2026-01-21 9:48 ` Christoph Hellwig
2026-01-21 10:34 ` NeilBrown
2026-01-21 14:27 ` Jeff Layton
2026-01-21 14:47 ` Christoph Hellwig
2026-01-21 15:18 ` Jeff Layton
2026-01-22 6:37 ` Christoph Hellwig
2026-01-22 12:12 ` Jeff Layton
2026-01-22 17:04 ` Darrick J. Wong
2026-01-21 12:37 ` Jeff Layton
2026-01-20 9:04 ` Christian Brauner
2026-01-20 9:41 ` NeilBrown
2026-01-20 10:31 ` Christian Brauner [this message]
2026-01-20 12:50 ` Jeff Layton
2026-01-21 3:58 ` NeilBrown
2026-01-21 11:56 ` Jeff Layton
2026-01-21 18:59 ` Amir Goldstein
2026-01-21 10:00 ` Christoph Hellwig
2026-01-21 10:01 ` Christoph Hellwig
2026-01-21 9:58 ` Christoph Hellwig
2026-01-21 9:52 ` Christoph Hellwig
2026-01-19 12:30 ` Jeff Layton
2026-01-21 4:10 ` NeilBrown
2026-01-15 18:31 ` Chuck Lever
2026-01-15 19:14 ` Amir Goldstein
2026-01-15 19:31 ` Amir Goldstein
2026-01-15 19:37 ` Chuck Lever
2026-01-15 19:47 ` Amir Goldstein
2026-01-15 21:09 ` Dave Chinner
2026-01-15 21:37 ` Chuck Lever
2026-01-15 22:40 ` David Laight
2026-01-19 7:56 ` Christoph Hellwig
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260120-hacken-revision-88209121ac2c@brauner \
--to=brauner@kernel.org \
--cc=Dai.Ngo@oracle.com \
--cc=adilger.kernel@dilger.ca \
--cc=agruenba@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=almaz.alexandrovich@paragon-software.com \
--cc=amarkuze@redhat.com \
--cc=amir73il@gmail.com \
--cc=anna@kernel.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=bharathsm@microsoft.com \
--cc=cem@kernel.org \
--cc=ceph-devel@vger.kernel.org \
--cc=chao@kernel.org \
--cc=chuck.lever@oracle.com \
--cc=clm@fb.com \
--cc=devel@lists.orangefs.org \
--cc=dhavale@google.com \
--cc=dsterba@suse.com \
--cc=dwmw2@infradead.org \
--cc=gfs2@lists.linux.dev \
--cc=guochunhai@vivo.com \
--cc=hch@infradead.org \
--cc=hirofumi@mail.parknet.co.jp \
--cc=hubcap@omnibond.com \
--cc=hughd@google.com \
--cc=idryomov@gmail.com \
--cc=jack@suse.com \
--cc=jack@suse.cz \
--cc=jaegeuk@kernel.org \
--cc=jefflexu@linux.alibaba.com \
--cc=jfs-discussion@lists.sourceforge.net \
--cc=jlayton@kernel.org \
--cc=jlbec@evilplan.org \
--cc=joseph.qi@linux.alibaba.com \
--cc=konishi.ryusuke@gmail.com \
--cc=lihongbo22@huawei.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-cifs@vger.kernel.org \
--cc=linux-erofs@lists.ozlabs.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-f2fs-devel@lists.sourceforge.net \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-mtd@lists.infradead.org \
--cc=linux-nfs@vger.kernel.org \
--cc=linux-nilfs@vger.kernel.org \
--cc=linux-unionfs@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=luisbg@kernel.org \
--cc=mark@fasheh.com \
--cc=martin@omnibond.com \
--cc=miklos@szeredi.hu \
--cc=neil@brown.name \
--cc=ntfs3@lists.linux.dev \
--cc=ocfs2-devel@lists.linux.dev \
--cc=okorniev@redhat.com \
--cc=pc@manguebit.org \
--cc=phillip@squashfs.org.uk \
--cc=richard@nod.at \
--cc=ronniesahlberg@gmail.com \
--cc=salah.triki@gmail.com \
--cc=sfrench@samba.org \
--cc=shaggy@kernel.org \
--cc=slava@dubeyko.com \
--cc=sprasad@microsoft.com \
--cc=tom@talpey.com \
--cc=trondmy@kernel.org \
--cc=tytso@mit.edu \
--cc=viro@zeniv.linux.org.uk \
--cc=xiang@kernel.org \
--cc=zbestahu@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox