On Mon 19-01-26 23:50:13, Christoph Hellwig wrote:
> On Mon, Jan 19, 2026 at 11:26:19AM -0500, Jeff Layton wrote:
> > + EXPORT_OP_STABLE_HANDLES - This filesystem provides filehandles that are
> > + stable across the lifetime of a file. This is a hard requirement for
> > export
> > + via nfsd. Any filesystem that is eligible to be exported via nfsd must
> > + indicate this guarantee by setting this flag. Most disk-based
> > filesystems
> > + can do this naturally. Pseudofilesystems that are for local reporting
> > and
> > + control (e.g. kernfs, pidfs, nsfs) usually can't support this.
>
> Suggested rewording, taking some of the ideas from Dave Chinners earlier
> comments into account:
>
> EXPORT_OP_STABLE_HANDLES - This filesystem provides filehandles that are
> stable across the lifetime of a file. A file in this context is an
> instantiated inode reachable by one or more file names, or still open
> after
> the last name has been unlinked. Reuses of the same on-disk inode
> structure
> are considered new files and must provide different file handles from the
> previous incarnation. Most file systems designed to store user data
> naturally provide this capability. Pseudofilesystems that are for local
> reporting and control (e.g. kernfs, pidfs, nsfs) usually can't support
> this.
>
> This flags is a hard requirement for export via nfsd. Any filesystem that
> is eligible to be exported via nfsd must indicate this guarantee by
> setting this flag.
I like this. It certainly makes the requirement of stability clearer to me
(with explanations before I couldn't quite see the difference between shmem
and kernfs). I'd note that fat or shmem (which are both exportable)
satisfy this only with reasonably high probability as they use
get_random_u32() for initializing their i_generation but I guess it's as
good as it gets for them.
Honza
--
Jan Kara <[email protected]>
SUSE Labs, CR
