On Tue, Dec 12, 2023 at 10:42:58AM +0100, Miklos Szeredi wrote: > On Tue, 12 Dec 2023 at 10:35, Christian Brauner <brauner@xxxxxxxxxx> wrote: > > > So taking a step back here, please. The original motivation for this > > discussion was restricted to handle btrfs - and now bcachefs as well. > > Both have a concept of a subvolume so it made sense to go that route. > > IOW, it wasn't originally a generic problem or pitched as such. > > > > Would overlayfs be able to utilize an extended inode field as well? > > Well, yes, but I don't think that's the right solution. 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. > > I think the right solution is to move to using file handles instead of > st_ino, the problem with that is that there's no way kernel can force > upgrading userspace. That's not our job tbh. I get why this is desirable. What we can do is advertise better and newer apis but we don't have to make unpleasant compromises in our interfaces for that. > > 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.
