Message-ID: <20260115224018.2988ca25@pumpkin>
Date: Thu, 15 Jan 2026 22:40:18 +0000
From: David Laight <david.laight.linux@...il.com>
To: "Chuck Lever" <cel@...nel.org>
Cc: "Dave Chinner" <david@...morbit.com>, "Amir Goldstein"
 <amir73il@...il.com>, "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, 15 Jan 2026 16:37:27 -0500
"Chuck Lever" <cel@...nel.org> wrote:

> On Thu, Jan 15, 2026, at 4:09 PM, Dave Chinner wrote:
> > On Thu, Jan 15, 2026 at 02:37:09PM -0500, Chuck Lever 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  
> >
> > <pedantic mode engaged>
> >
> > File handles most definitely change over the life of a /physical/
> > inode. Unlinking a file does not require ending the life of the
> > physical object that provides the persistent data store for the
> > file.
> >
> > e.g. XFS dynamically allocates physical inodes might in a life cycle
> > that looks somewhat life this:
> >
> > 	allocate physical inode
> > 	insert record into allocated inode index
> > 	mark inode as free
> >
> > 	while (don't need to free physical inode) {
> > 		...
> > 		allocate inode for a new file
> > 		update persistent inode metadata to generate new filehandle
> > 		mark inode in use
> > 		...
> > 		unlink file
> > 		mark inode free
> > 	}
> >
> > 	remove inode from allocated inode index
> > 	free physical inode
> >
> > i.e. a free inode is still an -allocated, indexed inode- in the
> > filesystem, and until we physically remove it from the filesystem
> > the inode life cycle has not ended.
> >
> > IOWs, the physical (persistent) inode lifetime can span the lifetime
> > of -many- files. However, the filesystem guarantees that the handle
> > generated for that inode is different for each file it represents
> > over the whole inode life time.
> >
> > Hence I think that file handle stability/persistence needs to be
> > defined in terms of -file lifetimes-, not the lifetimes of the
> > filesystem objects implement the file's persistent data store.  
> 
> Fair enough, "inode" is the wrong term to use here.

Usually there is 'generation number' changes when the inode is used for
a new file.
IIRC the original nfs file handle was the major/minor for the disk partition,
the index into the 'on-disk inode table' (the inode number) and the
'generation number' (but I'm sure the length was a power of 2...).

It's not surprising Unix uses inode number and file handles.
K&R would have used RSM-11/M where 'file directory lookup' was a userspace
operation and the kernel only supported 'open by file handle'.
Although that got lost between there and ntfs.
(Windows IO is definitely based on RSM-11/M though.)

	David

Powered by blists - more mailing lists