Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   "Frank Filz" <ffilzlnx@mindspring.com>
To:     "'NeilBrown'" <neilb@suse.de>
Cc:     "'J. Bruce Fields'" <bfields@fieldses.org>,
        "'Chuck Lever'" <chuck.lever@oracle.com>,
        <linux-nfs@vger.kernel.org>, "'Josef Bacik'" <josef@toxicpanda.com>
References: <162995209561.7591.4202079352301963089@noble.neil.brown.name>, <162995778427.7591.11743795294299207756@noble.neil.brown.name>, <20210826201916.GB10730@fieldses.org>, <163001583884.7591.13328510041463261313@noble.neil.brown.name>, <002901d79b53$41ddba40$c5992ec0$@mindspring.com>, <163010502766.7591.10398654528737145909@noble.neil.brown.name>, <005801d79b9d$b8437b80$28ca7280$@mindspring.com> <163010850148.7591.14454473128413118273@noble.neil.brown.name>
In-Reply-To: <163010850148.7591.14454473128413118273@noble.neil.brown.name>
Subject: RE: [PATCH v2] BTRFS/NFSD: provide more unique inode number for btrfs export
Date:   Fri, 27 Aug 2021 19:21:59 -0700
Message-ID: <005d01d79bb3$7b914c10$72b3e430$@mindspring.com>
MIME-Version: 1.0
Content-Type: text/plain;
        charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Content-Language: en-us
Thread-Index: AQIrHUOuRItKwhPpv5iuHWFXVceYzwFdY2wGAcm0L1ICXkcdJQIF8dZtApre6XMCCRVTjQEBoISGqnej5NA=
Precedence: bulk

> On Sat, 28 Aug 2021, Frank Filz wrote:
>=20
> > > 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.
>=20
> 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.
>=20
> 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.
>=20
> NeilBrown

Frank