Re: [PATCH 01/11] VFS: show correct dev num in mountinfo

["NeilBrown" <neilb@suse.de>]

On Fri, 30 Jul 2021, Miklos Szeredi wrote:
> On Fri, 30 Jul 2021 at 07:28, NeilBrown <neilb@suse.de> 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"

Thanks.
NeilBrown