Re: [PATCH][RFC] NFS: Propagate 'fsc' mount option through automounts

[Trond Myklebust <Trond.Myklebust@netapp.com>]

On Tue, 2009-07-14 at 18:47 +0100, David Howells wrote:
> Trond Myklebust <Trond.Myklebust@netapp.com> wrote:
> 
> > Why not just use the mount path as the default uniquifier?
> 
> Because:
> 
>  (1) Which mount path?  You're now constructing the mount tree in its own
>      private namespace.

The natural thing would be to use the mount path that is required to
locate the super block's root dentry on the server (i.e. the mount path
for sb->s_root).
In the private namespace (since that reflects the namespace of the
server, and hence mnt->mnt_root == sb->s_root) this mount path will
always be the same as the contents of mnt->mnt_devname. 

(In the local namespace, however, sb->s_root != mnt->mnt_root, and so
mnt->mnt_devname is fixed up to reflect that difference. See
nfs_fix_devname()...)

>  (2) Due to the new VFS-pathwalk-based mount, the uniquifier is applied to the
>      root mount only, and if modified to inherit, would be applied to every
>      automount subordinate to that, rather than just the actual subject of the
>      mount.
>
>  (3) Due to the new VFS-pathwalk-based mount and the private namespace, the
>      default uniquifier for all instances of any particular mount is always
>      the same.

...and is that sufficient? If it is, then fine, let's leave it...

>  (4) If we work around some how the mounts now getting their mount path from
>      the private namespace, there are still real namespaces, chroots and
>      root-pivots to contend with.

Real namespaces, chroots and root-pivots are all changes to the client
only. They do not change the server's namespace, and hence the mount
path is invariant.

     Trond

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@netapp.com
www.netapp.com