RE: [PATCH v2] BTRFS/NFSD: provide more unique inode number for btrfs export

["Frank Filz" <ffilzlnx@mindspring.com>]

> On Sat, 28 Aug 2021, Frank Filz wrote:
> 
> > > On Sat, 28 Aug 2021, Frank Filz wrote:
> > > >
> > > > Changing the fsid for sub-volumes is Ganesha's solution (before
> > > > adding that, we couldn't even export the sub-volumes at all).
> > >
> > > What does Ganesha use for the mounted-on-fileid? There doesn't seem
> > > to be an "obvious" answer so I wonder what was chosen.
> >
> > We only make mounted_on_fileid different from fileid on our export
> > boundaries, and even then, it's not a terribly correct thing for
> > FSAL_VFS (our module for interfacing with kernel filesystems) since
> > user space to my knowledge has no way to get any information on an
> > inode that serves as a mount point.
> 
> It is possible to see the mounted-on inode number by doing a readdir() of the
> parent directory and looking at d_ino.  It is a bit round-about.

Ahh, I'll have to keep that in mind, I'm not totally sure, but I think AIX mostly used/got the mounted_on_fileid during a READDIR which if that translates into a readdir to the underlying filesystem (via getdents in our case) then we have the d_ino to fill in mounted_on_fileid. I think it's less likely a situation with a LOOKUP. I think AIX used it when it got NFS4ERR_WRONGSEC when doing a READDIR, it would then go back and do a READDIR just asking for mounted_on_fileid (which as a property of the owning directory, we decided was OK to give for an inode that was in a new export with different security flavor requirements). I think AIX used the mounted_on_fileid to instantiate some kind of junction inode in the directory.

> >
> > What clients actually do anything with mounted_on_fileid, and what
> > sorts of things do they do with it? I know the AIX client was
> > interested in it (from having worked on security negotiation back in
> > 2006), but I have never been able to test Ganesha with an AIX client.
> > For normal Linux client operations, what Ganesha does seems to work
> > OK.
> 
> On the Linux client, if you stat() a directory that is a mountpoint on the server,
> you will see a directory with the inode number being the mounted-on-fileid.
> That directory is an automount-point, and when you access anything in it, the
> 'real' directory gets mounted and the mounted-on-fileid disappears.
> So if you reported a mounted-on-fileid the same as the fileid, which would be
> 256 on btrfs, du and find can get confused.  To be safe, the mounted-of-fileid
> needs to be different to all ancestors.
> 
> NeilBrown

Frank