Pseudofilesystem improvements
From Linux NFS
| Line 1: | Line 1: | ||
| + | See also [http://bugzilla.linux-nfs.org/show_bug.cgi?id=75 This bugzilla bug report]. | ||
| + | |||
While NFSv2 and NFSv3 use a separate mount protocol to discover a server's exported filesystems, NFSv4 uses the same standard filesystem protocol (lookup, readdir, etc.) that is used to traverse within filesystems. | While NFSv2 and NFSv3 use a separate mount protocol to discover a server's exported filesystems, NFSv4 uses the same standard filesystem protocol (lookup, readdir, etc.) that is used to traverse within filesystems. | ||
| Line 5: | Line 7: | ||
Rather than constructing the pseudofilesystem from the list of exports in the /etc/exports file, the nfsd server just uses a real filesystem as the pseudofilesystem, and the administrator to export filesystems mounted underneath it. So that the server knows which exported filesystem to use as the pseudofilesystem (the filesystem that NFSv4 clients will see as "/"), that filesystem is marked with the export option "fsid=0". | Rather than constructing the pseudofilesystem from the list of exports in the /etc/exports file, the nfsd server just uses a real filesystem as the pseudofilesystem, and the administrator to export filesystems mounted underneath it. So that the server knows which exported filesystem to use as the pseudofilesystem (the filesystem that NFSv4 clients will see as "/"), that filesystem is marked with the export option "fsid=0". | ||
| - | This system was relatively simple to implement, but | + | This system was relatively simple to implement, but has lead to severe problems for automount users, or for anyone attempting to migrate from NFSv2/v3 to v4, because v4 clients see different paths than mountd clients. |
| + | |||
| + | For example, to quote Trond: "the current system means that if your export file | ||
| + | looks like this: | ||
| + | /export/home myclient(rw,sync,no_subtree_check,fsid=0) | ||
| + | |||
| + | then that means that an NFSv4 fstab entry on 'myclient' will look like | ||
| + | |||
| + | myserver:/ /mnt nfs4 rw,hard,intr 0 0 | ||
| + | |||
| + | whereas an NFSv3 entry would look like | ||
| + | |||
| + | myserver:/export/home /mnt nfs rw,hard,intr 0 0 | ||
| + | |||
| + | This difference in path semantics means that there is no way we could | ||
| + | have 'mount' try NFSv4 first, then automatically fall back to NFSv3 if | ||
| + | the server doesn't support NFSv4. | ||
| + | What we ought to do (what Solaris, Netapp,... all do) is for the NFSv4 | ||
| + | server to have a pseudo-fs that contains the entries '/', '/export', and | ||
| + | '/export/home' so that the NFSv4 client can mount the | ||
| + | directory /export/home instead of '/'." | ||
Revision as of 18:51, 17 August 2006
See also This bugzilla bug report.
While NFSv2 and NFSv3 use a separate mount protocol to discover a server's exported filesystems, NFSv4 uses the same standard filesystem protocol (lookup, readdir, etc.) that is used to traverse within filesystems.
This gives the impression that these filesystems are all mounted on top of a top-level "pseudofilesystem".
Rather than constructing the pseudofilesystem from the list of exports in the /etc/exports file, the nfsd server just uses a real filesystem as the pseudofilesystem, and the administrator to export filesystems mounted underneath it. So that the server knows which exported filesystem to use as the pseudofilesystem (the filesystem that NFSv4 clients will see as "/"), that filesystem is marked with the export option "fsid=0".
This system was relatively simple to implement, but has lead to severe problems for automount users, or for anyone attempting to migrate from NFSv2/v3 to v4, because v4 clients see different paths than mountd clients.
For example, to quote Trond: "the current system means that if your export file looks like this: /export/home myclient(rw,sync,no_subtree_check,fsid=0)
then that means that an NFSv4 fstab entry on 'myclient' will look like
myserver:/ /mnt nfs4 rw,hard,intr 0 0
whereas an NFSv3 entry would look like
myserver:/export/home /mnt nfs rw,hard,intr 0 0
This difference in path semantics means that there is no way we could have 'mount' try NFSv4 first, then automatically fall back to NFSv3 if the server doesn't support NFSv4. What we ought to do (what Solaris, Netapp,... all do) is for the NFSv4 server to have a pseudo-fs that contains the entries '/', '/export', and '/export/home' so that the NFSv4 client can mount the directory /export/home instead of '/'."
