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 <[email protected]> wrote: >> >> >> >> >> >> >> >> On Thu, Jan 15, 2026, at 1:17 PM, Amir Goldstein wrote: >> >>> On Thu, Jan 15, 2026 at 6:48 PM Jeff Layton <[email protected]> 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. -- Chuck Lever _______________________________________________ Linux-f2fs-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
