On Tue, 12 Dec 2023 at 14:48, Christian Brauner <[email protected]> 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... Thanks, Miklos
