linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Handling of duplicate inode numbers for the directories in the nfs v3 kernel client
@ 2018-12-12 18:57 Ashish Sangwan
  2018-12-12 22:45 ` NeilBrown
  2018-12-13 16:26 ` Frank Filz
  0 siblings, 2 replies; 9+ messages in thread
From: Ashish Sangwan @ 2018-12-12 18:57 UTC (permalink / raw)
  To: linux-nfs, neilb

Hi,

Our NFS filer can sometimes return same inode number for different directories.
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?
https://lkml.org/lkml/2006/10/2/346
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.

Thanks,
Ashish

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Handling of duplicate inode numbers for the directories in the nfs v3 kernel client
  2018-12-12 18:57 Handling of duplicate inode numbers for the directories in the nfs v3 kernel client Ashish Sangwan
@ 2018-12-12 22:45 ` NeilBrown
  2018-12-13  3:47   ` Ashish Sangwan
  2018-12-13 16:26 ` Frank Filz
  1 sibling, 1 reply; 9+ messages in thread
From: NeilBrown @ 2018-12-12 22:45 UTC (permalink / raw)
  To: Ashish Sangwan, linux-nfs

[-- Attachment #1: Type: text/plain, Size: 1492 bytes --]

On Thu, Dec 13 2018, Ashish Sangwan wrote:

> Hi,
>
> Our NFS filer can sometimes return same inode number for different directories.

Why?

> 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.
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.

NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Handling of duplicate inode numbers for the directories in the nfs v3 kernel client
  2018-12-12 22:45 ` NeilBrown
@ 2018-12-13  3:47   ` Ashish Sangwan
  2018-12-13  3:55     ` NeilBrown
  2019-01-10 20:33     ` J. Bruce Fields
  0 siblings, 2 replies; 9+ messages in thread
From: Ashish Sangwan @ 2018-12-13  3:47 UTC (permalink / raw)
  To: neilb; +Cc: linux-nfs

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Handling of duplicate inode numbers for the directories in the nfs v3 kernel client
  2018-12-13  3:47   ` Ashish Sangwan
@ 2018-12-13  3:55     ` NeilBrown
  2019-01-10 20:33     ` J. Bruce Fields
  1 sibling, 0 replies; 9+ messages in thread
From: NeilBrown @ 2018-12-13  3:55 UTC (permalink / raw)
  To: Ashish Sangwan; +Cc: linux-nfs

[-- Attachment #1: Type: text/plain, Size: 2503 bytes --]

On Thu, Dec 13 2018, Ashish Sangwan wrote:

> 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?

No, the VFS layer won't notice duplicates.

NeilBrown


>
>> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Handling of duplicate inode numbers for the directories in the nfs v3 kernel client
  2018-12-12 18:57 Handling of duplicate inode numbers for the directories in the nfs v3 kernel client Ashish Sangwan
  2018-12-12 22:45 ` NeilBrown
@ 2018-12-13 16:26 ` Frank Filz
  2018-12-14  5:11   ` Ashish Sangwan
  1 sibling, 1 reply; 9+ messages in thread
From: Frank Filz @ 2018-12-13 16:26 UTC (permalink / raw)
  To: Ashish Sangwan, linux-nfs, neilb

On 12/12/18 10:57 AM, Ashish Sangwan wrote:
> Hi,
>
> Our NFS filer can sometimes return same inode number for different directories.
> 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?
> https://lkml.org/lkml/2006/10/2/346
> 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.
>
> Thanks,
> Ashish

The find tool will detect the collisions and report them, and if I 
recall it stops proceeding down the directory tree from the duplicate 
inode number. I know for sure I've seen it complain, and pretty sure I 
saw it stop descending the tree into the directory with the duplicate 
inode number.


Frank


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Handling of duplicate inode numbers for the directories in the nfs v3 kernel client
  2018-12-13 16:26 ` Frank Filz
@ 2018-12-14  5:11   ` Ashish Sangwan
  2018-12-17 11:06     ` Jeff Layton
  0 siblings, 1 reply; 9+ messages in thread
From: Ashish Sangwan @ 2018-12-14  5:11 UTC (permalink / raw)
  To: ffilz; +Cc: linux-nfs, neilb

On Thu, Dec 13, 2018 at 9:56 PM Frank Filz <ffilz@redhat.com> wrote:
>
> On 12/12/18 10:57 AM, Ashish Sangwan wrote:
> > Hi,
> >
> > Our NFS filer can sometimes return same inode number for different directories.
> > 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?
> > https://lkml.org/lkml/2006/10/2/346
> > 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.
> >
> > Thanks,
> > Ashish
>
> The find tool will detect the collisions and report them, and if I
> recall it stops proceeding down the directory tree from the duplicate
> inode number. I know for sure I've seen it complain, and pretty sure I
> saw it stop descending the tree into the directory with the duplicate
> inode number.
>

True. Was just looking into the find code to check how they detect cycles.
They are using pair of "device node : inode number" so find will
certainly complain.

>
> Frank
>

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Handling of duplicate inode numbers for the directories in the nfs v3 kernel client
  2018-12-14  5:11   ` Ashish Sangwan
@ 2018-12-17 11:06     ` Jeff Layton
  0 siblings, 0 replies; 9+ messages in thread
From: Jeff Layton @ 2018-12-17 11:06 UTC (permalink / raw)
  To: Ashish Sangwan, ffilz; +Cc: linux-nfs, neilb

On Fri, 2018-12-14 at 10:41 +0530, Ashish Sangwan wrote:
> On Thu, Dec 13, 2018 at 9:56 PM Frank Filz <ffilz@redhat.com> wrote:
> > On 12/12/18 10:57 AM, Ashish Sangwan wrote:
> > > Hi,
> > > 
> > > Our NFS filer can sometimes return same inode number for different directories.
> > > 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?
> > > https://lkml.org/lkml/2006/10/2/346
> > > 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.
> > > 
> > > Thanks,
> > > Ashish
> > 
> > The find tool will detect the collisions and report them, and if I
> > recall it stops proceeding down the directory tree from the duplicate
> > inode number. I know for sure I've seen it complain, and pretty sure I
> > saw it stop descending the tree into the directory with the duplicate
> > inode number.
> > 
> 
> True. Was just looking into the find code to check how they detect cycles.
> They are using pair of "device node : inode number" so find will
> certainly complain.
> 

You may also experience problems with some archiving tools -- e.g. tar,
cpio or rsync. Many of those programs rely on looking at inode numbers
to detect hardlinks.

Neil is quite right that the kernel NFS client generally doesn't care
about the inode number though.

-- 
Jeff Layton <jlayton@redhat.com>


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Handling of duplicate inode numbers for the directories in the nfs v3 kernel client
  2018-12-13  3:47   ` Ashish Sangwan
  2018-12-13  3:55     ` NeilBrown
@ 2019-01-10 20:33     ` J. Bruce Fields
  2019-01-26  8:39       ` Ashish Sangwan
  1 sibling, 1 reply; 9+ messages in thread
From: J. Bruce Fields @ 2019-01-10 20:33 UTC (permalink / raw)
  To: Ashish Sangwan; +Cc: neilb, linux-nfs

On Thu, Dec 13, 2018 at 09:17:31AM +0530, Ashish Sangwan wrote:
> 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.

Out of curiosity, why do you want to avoid submounts?

--b.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Handling of duplicate inode numbers for the directories in the nfs v3 kernel client
  2019-01-10 20:33     ` J. Bruce Fields
@ 2019-01-26  8:39       ` Ashish Sangwan
  0 siblings, 0 replies; 9+ messages in thread
From: Ashish Sangwan @ 2019-01-26  8:39 UTC (permalink / raw)
  To: J. Bruce Fields; +Cc: neilb, linux-nfs

On Fri, Jan 11, 2019 at 2:03 AM J. Bruce Fields <bfields@fieldses.org> wrote:
>
> On Thu, Dec 13, 2018 at 09:17:31AM +0530, Ashish Sangwan wrote:
> > 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.
>
> Out of curiosity, why do you want to avoid submounts?

Apologies for late reply. Didn't notice I have a new mail for this thread.
Some of the user space utils doesn't work well on mount points.
For example, "rm -rf" on the mount point doesn't work. (unlink fails with EBUSY)
GNU coreutils "mv" also doesn't work (rename fails with EBUSY)
(all-though even if sub-mounts are avoided, we give back EXDEV as part
of rename but that is internally handled by mv which performs
write/unlink in that case)
Every time user have to perform such operations, we have to tell them
to explicitly perform a umount first.
>
> --b.

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2019-01-26  8:39 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-12-12 18:57 Handling of duplicate inode numbers for the directories in the nfs v3 kernel client Ashish Sangwan
2018-12-12 22:45 ` NeilBrown
2018-12-13  3:47   ` Ashish Sangwan
2018-12-13  3:55     ` NeilBrown
2019-01-10 20:33     ` J. Bruce Fields
2019-01-26  8:39       ` Ashish Sangwan
2018-12-13 16:26 ` Frank Filz
2018-12-14  5:11   ` Ashish Sangwan
2018-12-17 11:06     ` Jeff Layton

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).