Message-ID: <CAOQ4uxhtorpd6FVsaGO=NdRD72MxeDyabip84ctQYSNufobS8w@mail.gmail.com>
Date: Thu, 15 Jan 2026 20:47:27 +0100
From: Amir Goldstein <amir73il@...il.com>
To: Chuck Lever <cel@...nel.org>
Cc: Jeff Layton <jlayton@...nel.org>, Christian Brauner <brauner@...nel.org>, 
	Alexander Viro <viro@...iv.linux.org.uk>, Chuck Lever <chuck.lever@...cle.com>, 
	NeilBrown <neil@...wn.name>, 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 Tso <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>, Christoph Hellwig <hch@...radead.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, 
	samba-technical@...ts.samba.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 Thu, Jan 15, 2026 at 8:37 PM Chuck Lever <cel@...nel.org> wrote:
>
> On 1/15/26 2:14 PM, Amir Goldstein wrote:
> > On Thu, Jan 15, 2026 at 7:32 PM Chuck Lever <cel@...nel.org> wrote:
> >>
> >>
> >>
> >> On Thu, Jan 15, 2026, at 1:17 PM, Amir Goldstein wrote:
> >>> On Thu, Jan 15, 2026 at 6:48 PM Jeff Layton <jlayton@...nel.org> wrote:
> >>>>
> >>>> In recent years, a number of filesystems that can't present stable
> >>>> filehandles have grown struct export_operations. They've mostly done
> >>>> this for local use-cases (enabling open_by_handle_at() and the like).
> >>>> Unfortunately, having export_operations is generally sufficient to make
> >>>> a filesystem be considered exportable via nfsd, but that requires that
> >>>> the server present stable filehandles.
> >>>
> >>> Where does the term "stable file handles" come from? and what does it mean?
> >>> Why not "persistent handles", which is described in NFS and SMB specs?
> >>>
> >>> Not to mention that EXPORT_OP_PERSISTENT_HANDLES was Acked
> >>> by both Christoph and Christian:
> >>>
> >>> https://lore.kernel.org/linux-fsdevel/20260115-rundgang-leihgabe-12018e93c00c@brauner/
> >>>
> >>> Am I missing anything?
> >>
> >> PERSISTENT generally implies that the file handle is saved on
> >> persistent storage. This is not true of tmpfs.
> >
> > That's one way of interpreting "persistent".
> > Another way is "continuing to exist or occur over a prolonged period."
> > which works well for tmpfs that is mounted for a long time.
>
> I think we can be a lot more precise about the guarantee: The file
> handle does not change for the life of the inode it represents. It
> has nothing to do with whether the file system is mounted.
>
>
> > But I am confused, because I went looking for where Jeff said that
> > you suggested stable file handles and this is what I found that you wrote:
> >
> > "tmpfs filehandles align quite well with the traditional definition
> >  of persistent filehandles. tmpfs filehandles live as long as tmpfs files do,
> >  and that is all that is required to be considered "persistent".
>
> I changed my mind about the name, and I let Jeff know that privately
> when he asked me to look at these patches this morning.
>
>
> >> The use of "stable" means that the file handle is stable for
> >> the life of the file. This /is/ true of tmpfs.
> >
> > I can live with STABLE_HANDLES I don't mind as much,
> > I understand what it means, but the definition above is invented,
> > whereas the term persistent handles is well known and well defined.
>
> Another reason not to adopt the same terminology as NFS is that
> someone might come along and implement NFSv4's VOLATILE file
> handles in Linux, and then say "OK, /now/ can we export cgroupfs?"
> And then Linux will be stuck with overloaded terminology and we'll
> still want to say "NO, NFS doesn't support cgroupfs".
>
> Just a random thought.

Good argument. I'm fine with stable as well :)

Thanks,
Amir.

Powered by blists - more mailing lists