On Thu, 30 May 2024 at 09:16, Christian Brauner <brauner@xxxxxxxxxx> wrote: > > On Wed, May 29, 2024 at 03:36:39PM -0300, Thiago Macieira wrote: > > First, the information provided by statfs(), which is the workaround. It's > > easy to call statfs() with the returned mount point path, though that causes a > > minor race. It's easy enough to shove struct statfs fields into struct statmount. I didn't do that for the first version to minimise the size of the patch but I think it makes sense. Even Linus suggested that this syscall should be an extended statfs(2), which implies that statfs info should be included. > > 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... > 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. I don't think we've promised that statmount(2) will only return mount information. In fact it does already return a fair amount of filesystem info as well. Note, stat/statx also return various bits and pieces, some inode some mount and some fs specific. I'd put fs options in there too, but that was something Christian disliked. We should have a discussion about how to retrieve options, and maybe the other things like label, devname, etc will fall out of that too. Thanks, Miklos
