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: 7bit
MIME-Version: 1.0
From:   "NeilBrown" <neilb@suse.de>
To:     "Christoph Hellwig" <hch@infradead.org>
Cc:     "J.  Bruce Fields" <bfields@fieldses.org>,
        "Chuck Lever" <chuck.lever@oracle.com>, linux-nfs@vger.kernel.org,
        "Josef Bacik" <josef@toxicpanda.com>
Subject: Re: [PATCH v2] BTRFS/NFSD: provide more unique inode number for btrfs export
In-reply-to: <YSkQ31UTVDtBavOO@infradead.org>
References: <162995209561.7591.4202079352301963089@noble.neil.brown.name>,
 <162995778427.7591.11743795294299207756@noble.neil.brown.name>,
 <YSkQ31UTVDtBavOO@infradead.org>
Date:   Sat, 28 Aug 2021 09:05:08 +1000
Message-id: <163010550851.7591.9342822614202739406@noble.neil.brown.name>
Precedence: bulk

On Sat, 28 Aug 2021, Christoph Hellwig wrote:
> On Thu, Aug 26, 2021 at 04:03:04PM +1000, NeilBrown wrote:
> > 
> > This patch allows btrfs (or any filesystem) to provide a 64bit number
> > that can be xored with the inode number to make the number more unique.
> > Rather than the client being certain to see duplicates, with this patch
> > it is possible but extremely rare.
> 
> Yikes.  Please don't do something like this that will eventually
> cause collisions.
> 
> 

There doesn't seem to be any other option - and this is still an
improvement over the current behaviour.

Collisions should still be quite a few years away, and there is hope
that the btrfs developers will take action before then to provide some
certainty.   Not much hope, but some.

NeilBrown