[RFC] [PATCH 0/6] Dynamic Pseudo Root
Steve Dickson
SteveD at redhat.com
Thu Oct 16 14:16:54 EDT 2008
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.
Unlike prior implementations, this implementations does not used bind mounts to define the pseudo root tree. Instead, simple directories are used as well as a new export flag which identifies the v4root to the kernel.
A 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 a directory tree mirroring the actual exported directories. These directories need to exist for lookups done by both mountd and the kernel.
Now when the PUTROOTFH comes in during the client mount, the /var/lib/nfs/v4root directory is returned as the root file handle. When subsequent GETFHs and LOOKUPs are done on the v4root, the kernel will make up-calls to rpc.mountd. In rpc.mountd the v4root directories are mapped to the real exported directories.
There is caveat when exporting different file systems. The fsid needs to be set in the export since switch uuids on the fly seems to cause havoc for both the Open Solaris and Linux clients. This is a rough edge and any suggestions on how to smooth this out will be more than welcomed...
Again unlike the previous implementation, there is some kernel supported needed. I was able to eliminate the bind mounts by introducing a new export flag. This flag signals the kernel that the current export is the pseudo root mountd needs to be consulted similar to what the bind mounts did.
comments?
steved.
More information about the NFSv4
mailing list