On Tue, Dec 12, 2023 at 04:53:28PM +1100, Dave Chinner wrote: > Doesn't anyone else see or hear the elephant trumpeting loudly in > the middle of the room? > > I mean, we already have name_to_handle_at() for userspace to get a > unique, opaque, filesystem defined file handle for any given file. > It's the same filehandle that filesystems hand to the nfsd so nfs > clients can uniquely identify the file they are asking the nfsd to > operate on. > > The contents of these filehandles is entirely defined by the file > system and completely opaque to the user. The only thing that > parses the internal contents of the handle is the filesystem itself. > Therefore, as long as the fs encodes the information it needs into the > handle to determine what subvol/snapshot the inode belongs to when > the handle is passed back to it (e.g. from open_by_handle_at()) then > nothing else needs to care how it is encoded. > > So can someone please explain to me why we need to try to re-invent > a generic filehandle concept in statx when we already have a > have working and widely supported user API that provides exactly > this functionality? Definitely should be part of the discussion :) But I think it _does_ need to be in statx; because: - we've determined that 64 bit ino_t just isn't a future proof interface, we're having real problems with it today - statx is _the_ standard, future proofed interface for getting inode attributes - therefore, if we want userspace programmers to be using filehandles, instead of inode numbers, so there code isn't broken, we need to be providing interfaces that guide them in that direction. Even assuming we can update all the documentation to say "filehandles are the correct way to test inode uniqueness", you know at least half of programmers will stick to stx_ino instead of the filehandle if the filehandle is an extra syscall.
