[PATCH 0/5] Dynamic Pseudo Root

[Trond Myklebust]

On Mon, 2008-02-18 at 07:32 -0500, 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?

As I've stated before, I'm not at all comfortable about having the
mountd daemon screw around with bind mounts. AFAICS there will be issues
when you decide to change an export. For instance, what will happen if I
were to remove /home/tmp from the export list, but the umount fails
because the partition happens to be in use by the server?

Nor am I particularly happy about using a tmpfs model for the pseudo-fs:
that will lead to broken clients when the server reboots and the
filehandles expire. May I remind you that there are _no_ clients out
there with working code for dealing with recovering expired filehandles.

IMO, the correct model for dealing with a pseudo-fs is the one that
Brent described, in which you use the real fs as a base, but black out
access to all non-directory dentries, and to all directory dentries that
are not listed as being visible to the client by the export list.

Cheers
  Trond