Managing NFS and NIS, 2nd Edition - Mike Eisler [112]
We'll take a look at how the user-level automounter works using the indirect auto_tools map discussed earlier. The NFS client host is named wahoo. From boot time, the complete sequence of events is:
The user-level automounter advertises the /tools mount point in /etc/mnttab, making it look like any other NFS-mounted filesystem except for the more verbose information about the server's IP address and port: /etc/mnttab excerpt
thud:/export/home/thud /tmp_mnt/home/thud nfs rw,dev=218980f 929944999
wahoo:(pid161) /tools nfs ro,ignore,map=/etc/auto_
tools,indirect,dev=2180009 920935886
The first mnttab entry is for a normal NFS mount point listed in the vfstab file. The second is for an indirect map and was added when the automounter was started. Instead of a server:directory pair, the automounter entry contains its process ID and the local host's name. The device numbers for NFS-mounted filesystems are simply unique values assigned by the kernel on each mount operation. This entry is added to mnttab when the automounter starts up and reads its maps.
A user goes to execute /tools/news/bin/rn. The kernel performs a lookup of the executable's pathname and finds that the tools component is a mount point. An NFS lookup request for the next component, news, is sent to the listed process — the automounter — via a loopback RPC mechanism.
The user-level automounter emulates a directory of symbolic links under the indirect map mount point. The lookup request on the news component is received by the automounter daemon, and it returns information identical to that received when performing a lookup on a symbolic link on a remote NFS server. The automounter looks up the appropriate filesystem in /etc/auto_tools and mounts it in its staging area, /tmp_mnt. This operation uses the mount( ) system call, which places a new entry in the mnttab file.
Now that the automounted filesystem has been referenced, the user-level automounter adds a symbolic link to its emulated directory. The new link in /tools points to the newly mounted filesystem. The equivalent command-line operations are: # mount thud:/tools3/news /tmp_mnt/tools/news
# ln -s /tmp_mnt/tools/news /tools/news
The client-side process receives the reply from its lookup request and goes to read the link. This time, the automounter returns the contents of the symbolic link, which points to the automounter staging area. Note that the automounter fabricates a response to the client's readlink request; it looks like there's a symbolic link on the disk but it's really an artifact of the automounter. The client process follows the link's target pathname to the appropriate subdirectory of /tmp_mnt.
The client process can now trace every pathname in /tools/news to a subdirectory of /tmp_mnt/tools/news, through the new entry in /etc/mnttab and the symbolic link emulation provided by the automounter. A client process pathname lookup finds /tools in the mount table and sends its query to the automounter. The automounter's link points to /tmp_mnt/news, which is also listed in the mount table. To the client, the automounter looks exactly like a directory and a symbolic link.
If this seems to be a convoluted mechanism for mounting a single filesystem, it is. However, this approach is taken to minimize the number of NFS mounts performed and to thereby improve performance by keeping /etc/mnttab as small as possible. When you mount several subdirectories of the same remote filesystem, only one NFS mount is required. The various subdirectories of this common mount point are referenced by symbolic links, not by individual mounts. In the sample indirect map earlier, mahimahi:/tools2 contains