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:
smime.p7s
Description: S/MIME cryptographic signature
