Re: [PATCH 00/29] fs: require filesystems to explicitly opt-in to nfsd export support

[NeilBrown <neilb@ownmail.net>]

On Tue, 20 Jan 2026, Christoph Hellwig wrote:
> On Tue, Jan 20, 2026 at 07:45:35AM +1100, NeilBrown wrote:
> > This sounds like you are recommending that we give in to bullying.
> 
> I find your suggestion that anything you disagree with is bullying
> extremely offensive.  If you have valid reasons for naming something
> after the user instead of explaining the semantics, please explain that.

I was referring not to your behaviour but to this statement by Christian:

  So if Christoph insists on the other name then I say let's just go with it.

I think that someone "insisting" on something rather than "arguing
rationally" for something "sounds like" bullying.  Had Christian said
something like "Christoph has convinced me of the wisdom of his choice"
that would have been very different.

I am quite happy to have reasoned discussions with people who disagree
with me.  I hope to always provide new relevant information, and hope
they will too.

> 
> If you think NFS actually explains the semantics pretty well, please
> explain that too, especially in forms that can be put into
> documentation, including for the user ABI.

There are multiple issues here:

 - filehandle stability.  As far as I know all filesystems provide
   stable filehandles when the "subtree_check" export option is not used.
   Certainly cgroupfs does.  So having an EXPORT_OP_STABLE_HANDLES
   flag would mean it was set for every filesystem - unless there is
   something else I'm not aware of.  That is certainly possible and I
   hope someone will let me know if I'm missing something.

 - filehandle uniqueness.  This is somewhat important and if a
   filesystem doesn't provide it, that should be considered a bug.  In a
   different thread Christian has observed that there would be benefit
   if pidfs and nsfs provided uniqueness across reboots.  It is quite
   easy for a virtual filesystem to generate a 64 bit random number when
   the fs is initialised, and include that in file handles.  Having a
   EXPORT_OP_REUSES_HANDLES flag could mark filesystems that are still
   buggy if that is thought to be useful.

 - GETATTR always reporting file size of 0.  This is the only concrete
   symptom that Jeff has reported (that I have seen).  This  makes it
   impossible to read files over NFS even if they have content.
   Would EXPORT_OP_INACCURATE_SIZE be useful?

 - maintainer feature choice.  A maintainer may choose not to support
   export over NFS because they feel that there is no value and the
   possible support burden would not be worth it.  There may be locking
   / lease / etc issues that further complicate things.  So it might be
   reasonable for a maintainer to choose to forbid NFS export while
   allowing local fhandle access. EXPORT_OP_NO_NFS_EXPORT.

It took me a while to sift through the code/patches/comments and come to
this understanding and I apologise if I wasn't as clear earlier.  But
my intuition was always that file handle stability was never the real
issue, and maintainer choice was.  Hence my rejection of the
"STABLE_HANDLES" name.

Thanks,
NeilBrown