On Thu, Dec 13 2018, Ashish Sangwan wrote: > Thanks for the clarification! > > On Thu, 13 Dec 2018, 4:15 am NeilBrown > >> 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