Re: Handling of duplicate inode numbers for the directories in the nfs v3 kernel client

[Ashish Sangwan <ashishsangwan2@gmail.com>]

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.