On Thu, 15 Jan 2026 16:37:27 -0500 "Chuck Lever" <[email protected]> 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 <[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. 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
