On Tue, 2020-02-25 at 12:13 +0000, Steven Whitehouse wrote: > Hi, > > On 24/02/2020 15:28, Miklos Szeredi wrote: > > On Mon, Feb 24, 2020 at 3:55 PM James Bottomley > > <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: > > > > > Once it's table driven, certainly a sysfs directory becomes > > > possible. The problem with ST_DEV is filesystems like btrfs and > > > xfs that may have multiple devices. > > > > For XFS there's always a single sb->s_dev though, that's what > > st_dev will be set to on all files. > > > > Btrfs subvolume is sort of a lightweight superblock, so basically > > all such st_dev's are aliases of the same master superblock. So > > lookup of all subvolume st_dev's could result in referencing the > > same underlying struct super_block (just like /proc/$PID will > > reference the same underlying task group regardless of which of the > > task group member's PID is used). > > > > Having this info in sysfs would spare us a number of issues that a > > set of new syscalls would bring. The question is, would that be > > enough, or is there a reason that sysfs can't be used to present > > the various filesystem related information that fsinfo is supposed > > to present? > > > > Thanks, > > Miklos > > > > We need a unique id for superblocks anyway. I had wondered about > using s_dev some time back, but for the reasons mentioned earlier in > this thread I think it might just land up being confusing and > difficult to manage. While fake s_devs are created for sbs that don't > have a device, I can't help thinking that something closer to > ifindex, but for superblocks, is needed here. That would avoid the > issue of which device number to use. > > In fact we need that anyway for the notifications, since without > that there is a race that can lead to missing remounts of the same > device, in case a umount/mount pair is missed due to an overrun, and > then fsinfo returns the same device as before, with potentially the > same mount options too. So I think a unique id for a superblock is a > generically useful feature, which would also allow for sensible sysfs > directory naming, if required, But would this be informative and useful for the user? I'm sure we can find a persistent id for a persistent superblock, but what about tmpfs ... that's going to have to change with every reboot. It's going to be remarkably inconvenient if I want to get fsinfo on /run to have to keep finding what the id is. The other thing a file descriptor does that sysfs doesn't is that it solves the information leak: if I'm in a mount namespace that has no access to certain mounts, I can't fspick them and thus I can't see the information. By default, with sysfs I can. James
