On Mon, Feb 24, 2020 at 3:55 PM James BottomleyWe 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.
<James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote:
Once it's table driven, certainly a sysfs directory becomes possible.For XFS there's always a single sb->s_dev though, that's what st_dev
The problem with ST_DEV is filesystems like btrfs and xfs that may have
multiple devices.
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