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>
In-Reply-To: <163010502766.7591.10398654528737145909@noble.neil.brown.name>
Subject: RE: [PATCH v2] BTRFS/NFSD: provide more unique inode number for btrfs export
Date:   Fri, 27 Aug 2021 16:46:12 -0700
Message-ID: <005801d79b9d$b8437b80$28ca7280$@mindspring.com>
MIME-Version: 1.0
Content-Type: text/plain;
        charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Content-Language: en-us
Thread-Index: AQIrHUOuRItKwhPpv5iuHWFXVceYzwFdY2wGAcm0L1ICXkcdJQIF8dZtApre6XOqj8wKwA==
Precedence: bulk

> 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).
>=20
> 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.

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.

> >
> > Mangling the fileid is definitely the best solution if there will be =
lots of sub-
> volumes. For a few sub-volumes changing fsid does create additional =
mount
> points on the client with some issues, but does guarantee there will =
be no fileid
> collision.
> >
> > My gut feel is your solution is the best one and Ganesha may need to =
switch to
> that solution.
>=20
> Thanks for the encouragement.  Changing the fsid does seem easier is =
many
> ways, but I don't really like the consequences or implications.

Yea, there really isn't a good solution here.

Probably really client applications need to do something different to =
detect infinite loops and not care so much about unique fileids.

Frank