On Tue, 2020-02-25 at 12:13 +0000, Steven Whitehouse wrote:
Hi,But would this be informative and useful for the user? I'm sure we can
On 24/02/2020 15:28, Miklos Szeredi wrote:
On Mon, Feb 24, 2020 at 3:55 PM James BottomleyWe need a unique id for superblocks anyway. I had wondered about
<James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote:
Once it's table driven, certainly a sysfs directory becomesFor XFS there's always a single sb->s_dev though, that's what
possible. The problem with ST_DEV is filesystems like btrfs and
xfs that may have multiple devices.
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
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,
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.
Yes, thats true, and I wasn't advocating for the sysfs method over fspick here, just pointing out that a unique superblock id would be a generically useful thing to have,
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