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:     "J.  Bruce Fields" <bfields@fieldses.org>
Cc:     "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: <20210827183216.GC3915@fieldses.org>
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>,
 <20210827183216.GC3915@fieldses.org>
Date:   Sat, 28 Aug 2021 09:01:48 +1000
Message-id: <163010530848.7591.9076942348960044071@noble.neil.brown.name>
Precedence: bulk

On Sat, 28 Aug 2021, J.  Bruce Fields wrote:
> On Fri, Aug 27, 2021 at 08:10:38AM +1000, NeilBrown wrote:
> > On Fri, 27 Aug 2021, J.  Bruce Fields wrote:
> > > On Thu, Aug 26, 2021 at 04:03:04PM +1000, NeilBrown wrote:
> > > > +	}
> > > > +	if (resp->dir_ino_uniquifier != ino)
> > > > +		ino ^= resp->dir_ino_uniquifier;
> > > 
> > > I guess this check (here and in nfsd_uniquify_ino) is just to prevent
> > > returning inode number zero?
> > 
> > Yep.  The set of valid inode numbers is 1..MAX and that set isn't closed
> > under xor.
> 
> I was curious....
> 
> The NFS specs don't require FILEID to be nonzero as far as I can tell.
> 
> Our client doesn't treat fileid 0 specially.  In the case it has to
> return a 32-bit inode it xors the high and low parts and makes no effort
> I can see to check for the 0 case.
> 
> I modified a server to return 0 for FILEID and MOUNTED_ON_FILEID on one
> particular file, and an strace shows that's happily passed on to
> userspace:
> 
> 	getdents64(3, [..., {d_ino=0, d_off=2048, d_reclen=32,
> 	d_type=DT_REG, d_name="LOCKTESTFILE"}]
> 
> But ls silently skips that file in the output.  Huh.
> 

What DO they teach in history class?
The original Unix File System (edition 6, 7 at least) had 16 bytes per
entry in directories (that could be read with read(2)).  Two bytes of
inode number and 14 bytes of name.
When a name was deleted, the inode number was over-written with '0'.
So code - and coders - from that era ignore directory entries with
d_ino==0.

I'm not certain what inode 0 was used for, but I think it had some
behind-the-scenes role.  Free-space?

So some code might work find with ino==0, but I'd rather not risk it.

NeilBrown