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;
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
From:   "NeilBrown" <neilb@suse.de>
To:     "Frank Filz" <ffilzlnx@mindspring.com>
Cc:     "'Miklos Szeredi'" <miklos@szeredi.hu>,
        "'Christoph Hellwig'" <hch@infradead.org>,
        "'J. Bruce Fields'" <bfields@fieldses.org>,
        "'Chuck Lever'" <chuck.lever@oracle.com>,
        "'Linux NFS list'" <linux-nfs@vger.kernel.org>,
        "'Josef Bacik'" <josef@toxicpanda.com>,
        linux-fsdevel@vger.kernel.org
Subject: RE: [PATCH v2] BTRFS/NFSD: provide more unique inode number for btrfs export
In-reply-to: <024601d7a005$1b3863c0$51a92b40$@mindspring.com>
References: <162995209561.7591.4202079352301963089@noble.neil.brown.name>,
 <162995778427.7591.11743795294299207756@noble.neil.brown.name>,
 <YSkQ31UTVDtBavOO@infradead.org>,
 <163010550851.7591.9342822614202739406@noble.neil.brown.name>,
 <YSnhHl0HDOgg07U5@infradead.org>,
 <163038594541.7591.11109978693705593957@noble.neil.brown.name>,
 <YS8ppl6SYsCC0cql@infradead.org>,
 <163055561473.24419.12486186372497472066@noble.neil.brown.name>,
 <YTB6NacU9bIOz2vf@infradead.org>,
 <CAJfpegu7rwoFXdtLusyRhrtFgMPxRShesxnBT2Q6iiC_iSGsfg@mail.gmail.com>,
 <024601d7a005$1b3863c0$51a92b40$@mindspring.com>
Date:   Fri, 03 Sep 2021 09:02:25 +1000
Message-id: <163062374563.24419.8930722817731828791@noble.neil.brown.name>
Precedence: bulk

On Fri, 03 Sep 2021, Frank Filz wrote:
> > On Thu, 2 Sept 2021 at 09:18, Christoph Hellwig <hch@infradead.org> wrote:
> >=20
> > > >  Your attitude seems to be that this is a btrfs problem and must be
> > > > fixed in btrfs.
> > >
> > > Yes.
> >=20
> > st_ino space issues affect overlayfs as well.   The two problems are
> > not the same, but do share some characteristics.  And this limitation wil=
l likely
> > come up again in the future.
> >=20
> > I suspect the long term solution would involve introducing new userspace =
API
> > (variable length inode numbers) and deprecating st_ino.
> > E.g. make stat return an error if the inode number doesn't fit into st_in=
o and add
> > a statx extension to return the full number.  But this would be a long pr=
ocess...
>=20
> But then what do we do where fileid in NFS is only 64 bits?

Hence my suggestion that user-space should move to using the filehandle.

Two file handles being different doesn't guarantee that the two objects
are different, but the problems caused by incorrectly assuming two
things are different are much less than the problems caused by
incorrectly assuming two things are the same.

>=20
> The solution of giving each subvol a separate fsid is the only real
> solution to enlarging the NFS fileid space, however that has downsides
> on the client side.

And this doesn't help overlayfs... =20

NeilBrown