[RFC,PATCH 0/4] Dynamic Pseudo Root

Chuck Lever chuck.lever at oracle.com
Fri Dec 7 14:38:15 EST 2007


On Dec 7, 2007, at 2:12 PM, Steve Dickson wrote:
> The following patch series gives rpc.mountd the ability to allocate
> a dynamic pseudo root, so the 'fsid=0' export option is no longer
> required. This allows v2, v3 and v4 clients mounts without any
> changes to the server's exports list.
>
> One anomaly of the Linux NFS server is that it requires a pseudo root
> to be defined. Currently the only way a pseudo root can be defined  
> is by
> setting the fsid to zero (i.e. fsid=0). So if we wanted to make v4
> the default mounting version and have things just work like v2/v3
> all of the existing exports configurations would have to change
> (i.e. a 'fsid=0' would have to be added) to support a v4 mounts,
> which, imho, is unacceptable. So this patch series address
> this problem.
>
> How it works:
>
> Working with Bruce Fields, it was decide to implement this
> functionality in userland (i.e. in rpc.mountd) by using existing
> utilities like tmpfs.Please remember this is an RFC, so this may not
> be the final solution, but it is a first step...
>
> The new '-R' command line argument, tells rpc.mountd to create a  
> pseudo root
> if and only if, one is not already defined. Meaning if there is an
> export entry in /etc/exports with an 'fsid=0' option, that entry
> will be the pseudo root and rpc.mountd will not create a root.

Why not make that the default behavior?  Is there a case when you  
need to switch this default behavior off?  (ie, why have a command  
line option to enable behavior that you need to have anyway).

> Now when a pseudo root is not defined, rpc.mountd will creates a  
> pseudo
> root in '/var/lib/nfs/v4root'. By create I mean, the /var/lib/nfs/ 
> v4root
> directory will be created and then be mounted as a tmpfs filesystem:
>
>     mount -t tmpfs tmpfs /var/lib/nfs/v4root
>
> Making /var/lib/nfs/v4root a true mount point.

What happens if there are more than one rpc.mountd processes running  
on the server?  Would having rpc.mound use a private namespace allow  
multiple instances to avoid colliding?

> Next, all the exported directories in the /etc/export file will
> be 'mount --bind' mounted under /var/lib/nfs/v4root. For example, for
> the following export entires:
>
>     /usr *(rw,nohide)
>     /home/tmp *(rw)
>
> will cause the following 'mount --bind's to occur.
>
>    mount --bind /usr /var/lib/nfs/v4root/usr
>    mount --bind /home/tmp /var/lib/nfs/v4root/home/tmp
>
> Now when the PUTROOTFH comes in from the client mount
> the /var/lib/nfs/v4root directory is returned as the
> root file handle. This means subsequent GETFHs and LOOKUPs
> will use file handle of /var/lib/nfs/v4root as the rootfh.
>
> Things do get a little tricky if the real root (i.e. '/')
> is exported. In this case, the real root becomes the pseudo
> root, regardless of how the fsid is or is not set. This became
> the easiest thing to do.
>
> This patches can be found on my experimental git tree:
>     git://linux-nfs.org/~steved/nfs-utils-exp nfs-utils.exp
> on the 'pseudo-v4root' branch.

--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com


More information about the NFSv4 mailing list