Re: file handle in statx (was: Re: How to cope with subvolumes and snapshots on muti-user systems?)

Miklos Szeredi
2023-12-12T14:06:21Z

On Tue, 12 Dec 2023 at 14:48, Christian Brauner <brauner@kernel.org> 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