>On Fri, 30 Jul 2021, Miklos Szeredi wrote: > On Fri, 30 Jul 2021 at 08:13, NeilBrown <neilb@xxxxxxx> wrote: > > > > On Fri, 30 Jul 2021, Miklos Szeredi wrote: > > > On Fri, 30 Jul 2021 at 07:28, NeilBrown <neilb@xxxxxxx> wrote: > > > > > > > > On Fri, 30 Jul 2021, Al Viro wrote: > > > > > On Wed, Jul 28, 2021 at 08:37:45AM +1000, NeilBrown wrote: > > > > > > /proc/$PID/mountinfo contains a field for the device number of the > > > > > > filesystem at each mount. > > > > > > > > > > > > This is taken from the superblock ->s_dev field, which is correct for > > > > > > every filesystem except btrfs. A btrfs filesystem can contain multiple > > > > > > subvols which each have a different device number. If (a directory > > > > > > within) one of these subvols is mounted, the device number reported in > > > > > > mountinfo will be different from the device number reported by stat(). > > > > > > > > > > > > This confuses some libraries and tools such as, historically, findmnt. > > > > > > Current findmnt seems to cope with the strangeness. > > > > > > > > > > > > So instead of using ->s_dev, call vfs_getattr_nosec() and use the ->dev > > > > > > provided. As there is no STATX flag to ask for the device number, we > > > > > > pass a request mask for zero, and also ask the filesystem to avoid > > > > > > syncing with any remote service. > > > > > > > > > > Hard NAK. You are putting IO (potentially - network IO, with no upper > > > > > limit on the completion time) under namespace_sem. > > > > > > > > Why would IO be generated? The inode must already be in cache because it > > > > is mounted, and STATX_DONT_SYNC is passed. If a filesystem did IO in > > > > those circumstances, it would be broken. > > > > > > STATX_DONT_SYNC is a hint, and while some network fs do honor it, not all do. > > > > > > > That's ... unfortunate. Rather seems to spoil the whole point of having > > a flag like that. Maybe it should have been called > > "STATX_SYNC_OR_SYNC_NOT_THERE_IS_NO_GUARANTEE" > > And I guess just about every filesystem would need to be fixed to > prevent starting I/O on STATX_DONT_SYNC, as block I/O could just as > well generate network traffic. Certainly I think that would be appropriate. If the information simply isn't available EWOULDBLOCK could be returned. > > Probably much easier fix btrfs to use some sort of subvolume structure > that the VFS knows about. I think there's been talk about that for a > long time, not sure where it got stalled. An easy fix for this particular patch is to add a super_operation which provides the devno to show in /proc/self/mountinfo. There are already a number of show_foo super_operations to show other content. But I'm curious about your reference to "some sort of subvolume structure that the VFS knows about". Do you have any references, or can you suggest a search term I could try? Thanks, NeilBrown
