[PATCH 0/5] Dynamic Pseudo Root

[Chuck Lever]

On Feb 18, 2008, at 7:32 AM, Steve Dickson wrote:
> Here is a second go around on the nfs-utils patches
> the implement dynamic pseudo root for NFS4 exports.
> This series includes changes from the review comments
> I received and a number of problems I found an along
> the way, but the overall design and functionality
> stayed the same.
>
> So in a nutshell here's how it works:
>
> 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.
>
> 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.
>
> 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.
>
> Now the main advantages to implementing this in userland is
> supportability as well as portability. Userlevel code,
> in general, is easier to support (and change) than kernel
> code. Plus, back porting this code to later releases will
> be much easier.
>
> Now the main drawback to this implementation could be scalability.
> Its not clear how well having a --bind mount for every export
> will scale. But only time will tell.
>
> In the end, I'm hopeful this will be the first toward making
> V4 the default version (replacing v3).
>
> Comments?

A couple of broad questions:

What happens if the kernel doesn't have support for tmpfs?  Do you  
provide a facility for falling back to a permanent file system type?

Can you compare your proposal to implementing the bind mounts and  
tmpfs pseudoroot in the NFS server start up scripts?  I'm curious if  
you doing much that requires specific and special support in mountd,  
etc. or is this just writing C code that could be implemented via a  
start-up script?  I like the idea of a user-space implementation, and  
given the relative simplicity of your proposal, creating a pseudoroot  
via shell scripting might be more flexible and less code.

I don't see anything that adjusts the pseudoroot bind mounts if an  
administrator comes by later and adds more exports or takes them  
away.  Is anything needed in "exportfs" to hook up new bind mounts,  
or remove ones that are going away?  Using an automounter here might  
be appropriate.

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