On Mon, Nov 06, 2023 at 11:03:37AM +0100, Christian Brauner wrote: > But why do we care? > Current code already does need to know it is on a btrfs subvolume. They > all know that btrfs subvolumes are special. "they all know" is a bit vague. How do you know "all" code knows? > They will need to know that > btrfs subvolumes are special in the future even if they were vfsmounts. > They would likely end up with another kind of confusion because suddenly > vfsmounts have device numbers that aren't associated with the superblock > that vfsmount belongs to. Let's take a step back. Posix says st_ino is uniqueue for a given st_dev, and per posix a mount mount is defined as any file that has a different st_dev from the parent. So by the Posix definition btrfs subvolume roots are mount points, which is am obvios clash with the Linux definition based on vfsmounts. > > > If userspace requests STATX_SUBVOLUME in the request mask, the two > > > filesystems raise STATX_SUBVOLUME in the statx result mask and then also > > > return the _real_ device number of the superblock and stop exposing that > > > made up device number. > > > > What is a "real" device number? > > The device number of the superblock of the btrfs filesystem and not some > made-up device number. The block device st_dev is just as made up. > I care about not making a btrfs specific problem the vfs's problem by > hoisting that whole problem space a level up by mapping subvolumes to > vfsmounts. While I'd love to fix it, and evern more not have more of this crap sneak in (*cough* bcachefs, *cough*). І'm ok with that stance. But that also means we can't let this creep into the vfs by other means, which is what started the thread.
