Message-ID: <f4c9cd498571f5bf976579ad33239408b1324258.camel@kernel.org>
Date: Wed, 21 Jan 2026 07:37:42 -0500
From: Jeff Layton <jlayton@...nel.org>
To: NeilBrown <neil@...wn.name>, Christoph Hellwig <hch@...radead.org>
Cc: Christian Brauner <brauner@...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 Tue, 2026-01-20 at 20:27 +1100, NeilBrown wrote:
> 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.
> 

I was conflating "uniqueness" with "stability" wrt cgroupfs. cgroupfs
does have _stable_ handles, by your definition above. What it does not
provide is proper uniqueness since it can end up reusing a filehandle
after a reboot. Maybe that is the better thing to flag here.


>  - 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?
> 

Ahh yes, that is probably why I was getting 0 length files when
reading. Likely fixable if anyone cares I suppose.

>  - 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 for laying all that out. You're quite right that this covers
more than handle stability.

At this point, I'm not sure what to do with this set since there are a
lot of competing proposals. In the near term, I'm fine with Amir's
patch.
-- 
Jeff Layton <jlayton@...nel.org>

Powered by blists - more mailing lists