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. Thanks, Miklos
