Re: statmount: requesting more information: statfs, devname, label

[Thiago Macieira <thiago.macieira@intel.com>]

[-- Attachment #1: Type: text/plain, Size: 2171 bytes --]

On Thursday 30 May 2024 05:25:39 GMT-3 Miklos Szeredi wrote:
> > > The second is the filesystem label. The workaround for this is opening
> > > the
> > > mount point and issuing ioctl(FS_IOC_GETFSLABEL), but that again
> > > introduces a minor race and also requires that the ability to open()
> > > the path in question. The second fallback to that is to scan
> > > /dev/disks/by-label, which is populated by udev/udisks/systemd.
> 
> FS_IOC_GETFSLABEL seems to be implemented only by a handful of
> filesystems.   I don't really undestand how this label thing works...

Nor I. It's one of the btrfs ioctl calls that became generic, like FICLONE, so 
it's not surprising that it isn't supported for all filesystems. For the rest, 
I guess udev/udisks knows the filesystem superblock header format and reads the 
label off it, because it seems to know the labels for FAT filesystems despite 
the system call not offering it.

openat(AT_FDCWD, "/boot/efi", O_RDONLY|O_CLOEXEC) = 4
statfs("/boot/efi", {f_type=MSDOS_SUPER_MAGIC, ...}) = 0
ioctl(4, FS_IOC_GETFSLABEL, 0x7ffe6f557110) = -1 ENOTTY

My code to decode this via /dev/disks/by-label is a best effort that seems to 
work for everything that doesn't support the ioctl. Fortunately, statmount() 
does give me the actual device's major/minor, no the anonymous IDs that some 
filesystems (like btrfs) use for subvolumes, so it's actually easier to scan 
with statmount() information.

> > I think that mnt_devname makes sense!
> > I don't like the other additions because they further blur the
> > distinction between mount and filesystem information.
> 
> mnt_devname is exactly that: filesystem information (don't let it fool
> you that it's in struct mount, that's just an historical accident).
> It's just a special option that customarily refers to a device path,
> but in general is very much filesystem specific.

Ah, good point. So here's even a stronger reason: if I had a remote FS, I'd 
probably want both the devname and the mount options, neither of which are in 
statmount() right now.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Principal Engineer - Intel DCAI Fleet Engineering and Quality

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5152 bytes --]