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:     "'Miklos Szeredi'" <miklos@szeredi.hu>,
        "'Christoph Hellwig'" <hch@infradead.org>
Cc:     "'NeilBrown'" <neilb@suse.de>,
        "'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>
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>
In-Reply-To: <CAJfpegu7rwoFXdtLusyRhrtFgMPxRShesxnBT2Q6iiC_iSGsfg@mail.gmail.com>
Subject: RE: [PATCH v2] BTRFS/NFSD: provide more unique inode number for btrfs export
Date:   Thu, 2 Sep 2021 07:16:21 -0700
Message-ID: <024601d7a005$1b3863c0$51a92b40$@mindspring.com>
MIME-Version: 1.0
Content-Type: text/plain;
        charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Content-Language: en-us
Thread-Index: AQIrHUOuRItKwhPpv5iuHWFXVceYzwFdY2wGAe8fACcBhmh95QIesfONAO3IHPoCbGx/fAGLnZteAStbb/8CEbYDYapxJ5Xg
Precedence: bulk

> 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 =
will 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_ino and add
> a statx extension to return the full number.  But this would be a long =
process...

But then what do we do where fileid in NFS is only 64 bits?

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.

Frank