> of a bubble. There is absolutely no implication that this is intentional > or even malicious. Ok, sometimes it's easy to miss nuances in mail which is why such comments are easy to misread. > > > > definition of a mount point, and that one used on basically every > > > other unix system. It might not work as-is for software that actually > > > particularly knows how to manage btrfs subvolumes, but those are, by > > > defintion, not the problem anyway. > > > > On current systems and since forever bind-mounts do not change device > > numbers unless they are a new filesystem mount. Making subvolumes > > vfsmounts breaks that. That'll mean a uapi change for > > /proc/<pid>/mountinfo for a start. > > a bind mount can of course change the dev_t - if it points to a > different super block at the moment. No, a bind mount just takes an existing directory tree of an existing filesystem and makes it visible on some location in the filesystem hierarchy. It doesn't change the device number it will inherit it from the superblock it belongs. mount -t xfs /dev/sda /mnt creates a new filesystem and a first mount for that filesystem. Any other additional bind-mount off of that will inherit the same device id in /proc/<pid>/mountinfo.
