[RFC,PATCH 0/4] Dynamic Pseudo Root

[Brent Callaghan]

This seems like a very complicated way to implement a pseudo root.

Why not implement it the same way as Solaris does it ?

When a Solaris NFSv4 server gets a PUTROOTFH it returns the client
the real filehandle for the real system root.  In fact, all  
filesystems that
may provide a path to a real export are automatically exported, albeit
with some simple restrictions:
	
	o LOOKUPs succeed only for path components that lead to
	   exported filesystems.

	o READDIR shows only path components that lead to exported
	   filesystems.

The pseudo filesystem is the same as the real filesystem, with
some restrictions.

The code to implement this was pretty straightforward.

	Brent


On Dec 7, 2007, at 11:12 AM, 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.
>
> 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.
>
> 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.
>
> comments?
>
> steved.
>
> _______________________________________________
> NFSv4 mailing list
> NFSv4 at linux-nfs.org
> http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4