On Tue, Dec 12, 2023 at 11:59:51AM +1100, NeilBrown wrote: > On Tue, 12 Dec 2023, Kent Overstreet wrote: > > On Tue, Dec 12, 2023 at 10:53:07AM +1100, NeilBrown wrote: > > > On Tue, 12 Dec 2023, Kent Overstreet wrote: > > > > On Tue, Dec 12, 2023 at 09:43:27AM +1100, NeilBrown wrote: > > > > > On Sat, 09 Dec 2023, Kent Overstreet wrote: > > > > Thoughts? > > > > > > > > > > I'm completely in favour of exporting the (full) filehandle through > > > statx. (If the application asked for the filehandle, it will expect a > > > larger structure to be returned. We don't need to use the currently > > > reserved space). > > > > > > I'm completely in favour of updating user-space tools to use the > > > filehandle to check if two handles are for the same file. > > > > > > I'm not in favour of any filesystem depending on this for correct > > > functionality today. As long as the filesystem isn't so large that > > > inum+volnum simply cannot fit in 64 bits, we should make a reasonable > > > effort to present them both in 64 bits. Depending on the filehandle is a > > > good plan for long term growth, not for basic functionality today. > > > > My standing policy in these situations is that I'll do the stopgap/hacky > > measure... but not before doing actual, real work on the longterm > > solution :) > > Eminently sensible. > > > > > So if we're all in favor of statx as the real long term solution, how > > about we see how far we get with that? > > > > I suggest: > > STATX_ATTR_INUM_NOT_UNIQUE - it is possible that two files have the > same inode number > > > __u64 stx_vol Volume identifier. Two files with same stx_vol and > stx_ino MUST be the same. Exact meaning of volumes > is filesys-specific > > STATX_VOL Want stx_vol > > __u8 stx_handle_len Length of stx_handle if present > __u8 stx_handle[128] Unique stable identifier for this file. Will > NEVER be reused for a different file. > This appears AFTER __statx_pad2, beyond > the current 'struct statx'. > STATX_HANDLE Want stx_handle_len and stx_handle. Buffer for > receiving statx info has at least > sizeof(struct statx)+128 bytes. Hmmm. 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? Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx
