Managing NFS and NIS, 2nd Edition - Mike Eisler [114]
The autofs 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 /home/thud nfs nosuid,dev=218980f 929944999
auto_tools /tools autofs
ignore,indirect,nosuid,dev=2b40002 922482272
The first mnttab entry is for a normal NFS mount point listed in the vfstab file. Note that the mount point is /home/thud and not /tmp_mnt/home/thud. The second is for an indirect map and was added when the automounter was started. Instead of a process ID and the local host's name, the entry simply has the map name and a filesystem type of autofs. The device numbers for autofs-mounted filesystems are 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. The kernel invokes the lookup entry point of the autofs filesystem request for tools. The kernel then proceeds to the next component in the pathname, news, and again invokes the lookup entry point of autofs. The autofs filesystem sends a request to the automounter daemon (automountd ) — via a loopback RPC mechanism — to mount news.
The automounter daemon receives the request from autofs. The request includes the name of the map (auto_tools), the entry in the map autofs is interested in (news), and the mount point the client wants to mount news onto (/tools/news). The automounter daemon examines the tools indirect map looking for the entry: news thud:/tools3/news
The automounter daemon checks if /tools/news exists, and if not, creates the news directory under /tools. Because /tools is an autofs filesystem, the result of the mkdir( ) system call from the daemon is a call to the mkdir entry point in the autofs filesystem.
The automounter daemon then determines that the news map entry is to be satisfied by NFS, and so does the equivalent of: # mount -F nfs thud:/tools3 /tools/news
The results of the mount are returned — again, via a loopback RPC mechanism — to autofs.
The autofs filesystem receives the reply from the automounter daemon, and now the kernel can proceed with the next components in the pathname, bin and rn. Because the automounter daemon mounted an NFS filesystem onto /tools/news, the automounter is not involved in the processing of bin and rn.
As with the user-level automounter, the original autofs automounter didn't display potential mounts of indirect maps like auto_tools. The next section describes an enhanced autofs automounter that supports the ability to browse the potential mounts under a mount point such as /tools.
The enhanced autofs automounter: Browsing indirect maps
In Solaris 2.6, the autofs automounter was modified so that displaying directories of the mount points of indirect maps shows every entry; in other words, it allows a user to browse the map:
% cd /tools
% ls -l
total 4
dr-xr-xr-x 1 root root 19 Aug 31 12:59 bugview
dr-xr-xr-x 1 root root 19 Aug 31 12:59 deskset
dr-xr-xr-x 1 root root 19 Aug 31 12:59 news
dr-xr-xr-x 1 root root 19 Aug 31 12:59 sting
When the readdir entry point in the autofs filesystem is called on /tools for the first time, there are no autofs directories underneath it, and so, autofs makes an RPC call to the automounter daemon to read the auto_tools map to return the list of map entries. The map entries are used to construct a directory listing for the ls command. Note that the attributes of the directories are faked. This is because we want to avoid mount storms, as described in Section 9.1.2.1.
Now see what happens we start to populate /tools with real entries:
% ls /tools/news
bin lib spool
% cd /tools
% ls -l
total 1
dr-xr-xr-x 1 root root 19 Aug 31 12:59 bugview
dr-xr-xr-x 1 root root 19 Aug 31 12:59 deskset