On Tue, Dec 12, 2023 at 03:06:07PM +0100, Miklos Szeredi wrote: > On Tue, 12 Dec 2023 at 14:48, Christian Brauner <brauner@xxxxxxxxxx> wrote: > > > Exposing the subvolume id in statx() is still fine imho. It's a concept > > shared between btrfs and bcachefs and it's pretty useful for interested > > userspace that wants to make use of these apis. > > Exposing subvolume ID should be okay, as long as it's not advertised > as a way to uniquely identify an inode. Its use should be limited to > finding subvolume boundaries. > > > > It might help to have the fh in statx, since that's easier on the > > > userspace programmer than having to deal with two interfaces (i_ino > > > won't go away for some time, because of backward compatibility). > > > OTOH I also don't like the way it would need to be shoehorned into > > > statx. > > > > No, it really doesn't belong into statx(). > > > > And besides, the file handle apis name_to_handle_at() are already > > in wider use than a lot of people think. Not just for the exportfs case > > but also for example, cgroupfs uses file handles to provide unique > > identifiers for cgroups that can be compared. > > The issue with name_to_handle_at() is its use of the old, non-unique > mount ID. Yes, yes, we can get away with > > fd = openat(dfd, path, O_PATH); > name_to_handle_at(fd, "", ..., AT_EMPTY_PATH); > statx(fd, "", AT_EMPTY_PATH, STATX_MNT_ID_UNIQUE, ...); > close(fd); > > But that's *four* syscalls instead of one... Yeah, but putting this into statx() isn't really nice imho. Once we do actually land the unique mount id thing it wouldn't be the worst thing to add name_to_handle_at2().
