DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EFC9620873
MIME-Version: 1.0
References: <CAOiN93mX240ijc8mcX1OSKrQaP12At9t5c9cE3-T0gEuLC9RkA@mail.gmail.com>
 <878t0uuzxv.fsf@notabene.neil.brown.name>
In-Reply-To: <878t0uuzxv.fsf@notabene.neil.brown.name>
From:   Ashish Sangwan <ashishsangwan2@gmail.com>
Date:   Thu, 13 Dec 2018 09:17:31 +0530
Message-ID: <CAOiN93=bh8WrCD8gZ+En4EfzTv2iHMn5n4w5=rYJOr6RbUkCKQ@mail.gmail.com>
Subject: Re: Handling of duplicate inode numbers for the directories in the
 nfs v3 kernel client
To:     neilb@suse.com
Cc:     linux-nfs@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Sender: linux-nfs-owner@vger.kernel.org
Precedence: bulk

Thanks for the clarification!

On Thu, 13 Dec 2018, 4:15 am NeilBrown <neilb@suse.com wrote:
>
> On Thu, Dec 13 2018, Ashish Sangwan wrote:
>
> > Hi,
> >
> > Our NFS filer can sometimes return same inode number for different directories.
>
> Why?
The NFS fileserver is handling file systems over different nodes at
the same time.
To the client however, we want to present with a single pseudo fsid
(sent as part of the getattr) so that submounts can be avoided.
We have assigned unique numbers to identify different file systems and
we append those numbers to the actual on-disk inode numbers to avoid
the collision.  But in some rare cases there is not enough free bits
in the inode to accommodate the unique filesystem identifier.

>
> > For example /mnt/dir1/dir2 and /mnt/dir3/dir4, in same rare cases dir2
> > and dir4 might end up returning the same inode number to the client.
> > Though it can never happen that inode numbers will be same for two
> > directories and also there parent is same. Can linux client handle
> > this case? What issues it can cause?
>
> As long as the file handles are different, the Linux client won't really
> notice.
A naive question here. This should also not cause any issue in the VFS layer?

> Problems might occur with applications which check inode numbers.
> I don't know of any that would be confused by directories having the
> same inode number, but that doesn't mean there aren't any.
>
> > https://lkml.org/lkml/2006/10/2/346
>
> This is ancient!  It is mostly about the NFS server, not the client.
> Filesystems that NFSd is exporting need to be careful to provide unique
> file handles.
>
> > I stumbled upon this thread where it is written that nfs client can
> > handle this but userspace will see inode collisions. Given that this
> > will happen only for directories, userspace utils logic might not get
> > affected from this as hardlinks on directories are not possible. But
> > the thread is really old. Wanted to confirm if this holds true even
> > now.
>
> I don't think anything important has changed.  The server must return
> unquie filehandles.  It should return unique inode numbers.  User-space
> may or may not get confused if it doesn't.
Understood that this has to be fixed ultimately. Just wanted to have
an idea regarding the severity of the issue.
>
> NeilBrown