On Thu, Nov 02, 2023 at 12:07:47PM +0100, Christian Brauner wrote: > But at that point we really need to ask if it makes sense to use > vfsmounts per subvolume in the first place: > > (1) We pollute /proc/<pid>/mountinfo with a lot of mounts. > (2) By calling ->getattr() from show_mountinfo() we open the whole > system up to deadlocks. > (3) We change btrfs semantics drastically to the point where they need a > new mount, module, or Kconfig option. > (4) We make (initial) lookup on btrfs subvolumes more heavyweight > because you need to create a mount for the subvolume. > > So right now, I don't see how we can make this work even if the concept > doesn't seem necessarily wrong. How else do you want to solve it? Crossing a mount point is the only legitimate boundary for changing st_dev and having a new inode number space. And we can't fix that retroactively.
