[PATCH 00/29] fs: require filesystems to explicitly opt-in to nfsd export support
Christian Brauner
brauner at kernel.org
Tue Jan 20 02:31:54 PST 2026
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.
More information about the linux-mtd
mailing list