On Fri, 2018-12-14 at 10:41 +0530, Ashish Sangwan wrote: > On Thu, Dec 13, 2018 at 9:56 PM Frank Filz <ffilz@xxxxxxxxxx> 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@xxxxxxxxxx>
