The automounter is included in Solaris, Compaq's Tru64 Unix, SGI's IRIX, IBM's AIX, and other commercial Unix operating systems. A public domain version called amd is available on http://www.cs.columbia.edu/~ezk/am-utils/ and amd runs on almost any Unix system. Because it is kernel- and server-independent, the amd automounter is easily migrated to other NFS client platforms.Why would you want to bother with another administrative tool? What's wrong with putting all of the remote filesystem information in each hosts' /etc/vfstab file? There are many motivations for using the automounter:
Adding NFS servers is usually accompanied by a juggling of directories. It is likely that every client will be required to mount filesystems from the new server. As new NFS servers add filesystems to the network, the clients develop new dependencies on these servers, and their vfstab files grow in complexity.
Users cannot simply mount filesystems at their whim without root privileges. The automounter handles this problem by performing the mount as the filesystems are referenced, which is usually the point at which users decide they need to perform the mount themselves. Some users request that their machines mount only those filesystems of interest to them to eliminate the possibility that their machines will hang if a server containing "uninteresting" files hangs. The automounter eliminates dependencies on these unrelated NFS servers by imposing a working-set notion on the set of mounted filesystems. When a filesystem is first referenced, the automounter mounts it at the appropriate place in the local filesystem. After several minutes (ten by default), the automounter attempts to unmount all filesystems that it previously mounted. If the filesystem is quiescent, and therefore probably uninteresting to the client, then the automounter's umount( ) system call succeeds, and the client is relieved of the server dependency. If the filesystem is busy, the automounter ignores the error returned by umount( ).
Using the automounter also adds another level of transparency to the network. Once a client's /etc/vfstab file is created, the client has a static idea of where each remote filesystem is located. It becomes difficult for the system administrator to move tools, users, or any other directory without going to each host and changing the /etc/vfstab files to reflect the change. The automounter makes the location of NFS filesystems even more transparent to NFS clients by removing hardcoded server names and pathnames from the clients' /etc/vfstab files.
Placing NFS filesystems in automounter maps greatly simplifies the administrative overhead of adding or reconfiguring NFS servers. Because the maps may be maintained using NIS, a single file is propagated to all NFS clients. Editing the individual /etc/vfstab files is not required. The automounter is also conducive to simpler mounting schemes. For example, mounting 50 directories of tools and utilities under /tools produces an unwieldy vfstab file. In addition, the tools mount point becomes a bottleneck, since any directory stat( ) or getwd( ) call that touches it also touches all NFS servers with filesystems mounted in /tools. More frequently, tools and utilities are mounted haphazardly, creating administrative problems. Simply remembering where things are is difficult, as users become confused by irregular naming schemes.
Managing /tools with the automounter offers several advantages. All of the individual mount points are replaced by a single map that creates the appropriate mount points as needed. The automounter mount point contains only the handful of entries corresponding to the working set of tools that the user employs at any one time. It's also much simpler to add a new tool: instead of having to create the mount point and edit /etc/vfstab on every host in the network, you simply update the NIS-managed automounter map.
Finally, the automounter looks for a filesystem on one of several servers. Manual pages, read-only libraries, and other replicated filesystems will be mounted from the first server in a set to respond to the mount request. In addition to providing a simple load-balancing scheme similar to that of NIS, the automounter removes single-host dependencies that would make a diskless or dataless workstation unusable in the event of a server crash.
Direct and indirect maps vary in how the automounter emulates the underlying mount point. For a direct map, the automounter looks like a symbolic link at each mount point in the map. With an indirect map, the automounter emulates a directory of symbolic links, where the directory is the common pathname prefix shared by all of the automounter-managed mount points. This is confusing and is best explained by the examples that follow.
The master map is a meta-map (a map describing other maps). It contains a list of indirect maps and direct mount points and tells the automounter where to look for all of its map information. We'll look at a typical master map after seeing how the indirect and direct maps are used to mount NFS filesystems.
Each indirect map has a directory associated with it that is specified on the command line or in the master map (see Section 9.2.1, "The master map" later in this chapter). The map itself contains a key, which is the name of the mount point in the directory, optional NFS mount options, and the server:pathname pair identifying the source of the filesystem. Automounter maps are usually named auto_contents, where contents describes the map. The map name does not have to correspond to its mount point -- it can be anything that indicates the map's function. Maps are placed in /etc or maintained via NIS.
The best way to understand how an indirect map works is to look at an example. We'll look at an automounter map and equivalent vfstab file for a directory structure like this:
Here is an indirect automounter map for the /tools directory, called auto_tools:/tools/deskset /tools/sting /tools/news /tools/bugview
The first field is called the map key and is the final component of the mount point. The map name suffix and the mount point do not have to share the same name, but adopting this convention makes it easy to associate map names and mount points. This four-entry map is functionally equivalent to the /etc/vfstab excerpt:deskset -ro mahimahi:/tools2/deskset sting mahimahi:/tools2/sting news thud:/tools3/news bugview jetstar:/usr/bugview
Notice that the server-side mount points have no common pathname prefixes, but that the client's vfstab and automounter map establish a regularly named view of filesystems.mahimahi:/tools2/desket - /tools/deskset nfs - - ro mahimahi:/tools2/string - /tools/sting nfs - - thud:/tools3/news - /tools/news nfs - - jetstar:/usr/bugview - /tools/bugview nfs - -
There are basically two kinds of automounters: older ones that use symbolic links and newer ones that don't. Using the auto_tools map, older implementations of the automounter emulate tools in a directory of symbolic links. When any process on the client makes a reference to something in /tools, the automounter completes the appropriate NFS mount and makes a symbolic link in /tools pointing to the actual mount point for the filesystem. Suppose you go to execute /tools/news/bin/rn. Using the automounter effectively breaks this pathname up into three components:
Note that the automounter map doesn't contain any information about the /tools directory itself, only about the subdirectories in it that are used for mount points. This makes it extremely easy to relocate a set of mount points -- you simply change the master map that associates the directory /tools with the map auto_tools. We'll come back to the master map later on.
As mentioned before, automounter implementations come in two designs. The first one is a purely user-level approach that relies heavily on symbolic links. The second is a hybrid user-level and kernel-level approach called the autofs automounter, which eschews symbolic links.
Before walking through the sequence of automounter operations in detail, some knowledge of mount information is necessary. The mount( ) system call takes the filesystem type (ufs, nfs, hsfs, etc.) and mount point from the /etc/vfstab table, and a packet of parameters that are type-specific. For NFS mounts, the argument vector passed to mount( ) includes the server's hostname and a socket address (IP host address and port number pair) to be used for sending requests to that server. For normal NFS mounts, the remote server's hostname and IP address are used, and the IP port number is the well-known NFS port number 2049. The kernel uses this information to put together an RPC client handle for calling the remote NFS server.
User-level automounters capitalize on this architecture by creating a set of mount arguments that points to itself, a process on the local host, with a different port number than 2049. In effect, a system running the automounter has mounted a daemon on each mount point, instead of a remote filesystem. NFS requests for these mount points are intercepted by the automounter, since it appears to be a regular, remote NFS server to the kernel. No kernel modifications are necessary to run the automounter, and the automounter's functions are transparent to user processes.
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./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
# mount thud:/tools3/news /tmp_mnt/tools/news # ln -s /tmp_mnt/tools/news /tools/news
The staging area /tmp_mnt is a key to the indirect map mechanism. If the staging area concept is eliminated, then the indirect map mount point becomes another directory filled with direct mounts. The primary advantage of indirect maps is that they allow the mount points in a directory to be managed independently -- the mounts occur when a process references the mount point, and not the parent directory itself. We'll look at some problems with direct mounts shortly.
As a result of linking /tools to the actual NFS mount point, a user would encounter the following:
In other words, instead of pwd displaying /tools/bin, it gets /tmp_mnt/tools/bin. This behavior breaks lots of software. For example, a program might record the current working directory, and cache it in a file. A subsequent invocation of the program might read the cache, and attempt to access /tmp_mnt/tools/bin, and find that it isn't there. This is because a user-level automounter responds to attempts to access /tools, not /tmp_mnt/tools. For the remainder of this chapter, we will refer to this issue as the "pwd problem."% cd /tools/bin % /usr/bin/pwd /tmp_mnt/tools/bin
There are other side-effects of the user-level automounter that may catch the user off-guard. The automounter creates and controls the indirect map mount point. It emulates the entire directory, so that no user, even the superuser, can create entries in it. This has an important implication for creating indirect maps: they cannot be mounted over an existing directory, because the automounter hides the underlying files. If a directory must contain a mixture of automounter mount points and "normal" directory entries, a direct map must be used.
This is an important but subtle point: when you poke at a user-level automounter mount point with ls, it appears that there is a directory filled with symbolic links. In reality, this directory and the links in it do not exist on any disk. If this hurts to think about, it's really no different than the way NFS itself works: there may be no filesystem called /tools/news on your local disk, but NFS makes it look like it's there. The user-level automounter speaks to the NFS protocol, allowing it to fabricate replies to NFS RPC calls that are indistinguishable from the real thing.
Because the user-level automounter controls the contents of a readdir NFS RPC reply, ls behaves strangely. The user-level automounter displays only currently mounted links in the directory it emulates. If no reference is made to a subdirectory of the indirect map directory, it appears empty:
Why not display potential mounts as well? Doing so could result in a great deal of unintended mounting activity -- a mount storm -- when ls -l is executed in this directory. A newer automounter described in the next section allows you to browse potential mounts, as well as fix the pwd problem described earlier. Another approach is to use hierarchical mounts, as described later in this chapter.% cd /tools % ls % ls /tools/news bin lib spool % cd /tools % ls -l total 1 lrwxrwxrwx 1 root 19 Aug 31 12:59 news -> /tmp_mnt/tools/news
Let's take a look at how adding autofs changes how the automounter works using the example of the indirect auto_tools map. The NFS client host is still named wahoo. From boot time, the complete sequence of events is:
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./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 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.news thud:/tools3/news
The automounter daemon then determines that the news map entry is to be satisfied by NFS, and so does the equivalent of:
The results of the mount are returned -- again, via a loopback RPC mechanism -- to autofs.# mount -F nfs thud:/tools3 /tools/news
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 184.108.40.206, "User-level automounters".% 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
Now see what happens we start to populate /tools with real entries:
Invoking the ls command on /tools/news causes /tools/news to be NFS-mounted from thud:/tools3/news. When the readdir entry point in the autofs filesystem is called on /tools for the second time, there is now an NFS directory, news, underneath it. Thus, autofs combines the list of map entries with the list of NFS-mounted directories.% 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 drwxrwxr-x 5 root other 512 Jun 10 17:03 news dr-xr-xr-x 1 root root 19 Aug 31 12:59 sting
The key in a direct map is a full pathname, instead of the last component found in the indirect map. Direct maps also follow the /etc/auto_contents naming scheme. Here is a sample /etc/auto_direct:
The automounter registers the entire direct mount point pathname in the mnttab file, instead of the parent directory of all of the mount points:/usr/man wahoo:/usr/share/man /usr/local/bin mahimahi:/usr/local/bin.sun4
The mnttab entry's map type is listed as direct. Operation of the automounter on a direct mount point is similar to the handling of an indirect mount. The autofs automounter is passed the entire direct mount point pathname in the RPC from autofs, since the mount point is the key in the map. See Table 9-1 for automounter map entry formats.auto_direct /usr/local/bin autofs ignore,direct,intr,ro,dev=2cc000a 933723158
A major difference in behavior is that the real direct mount points are always visible to ls and other tools that read directory structures. The automounter treats direct mounts as individual directory entries, not as a complete directory, so the automounter gets queried whenever the directory containing the mount point is read. Client performance is affected in a marked fashion if direct mount points are used in several well-traveled directories. When a user reads a directory containing a number of direct mounts, the automounter initiates a flurry of mounting activity in response to the directory read requests. Section 9.5.3, "Conversion of direct maps" describes a trick that lets you use indirect maps instead of direct maps. By using this trick, you can avoid mount storms caused by multiple direct mount points.
indirect map: deskset
direct map: /usr/man
|8.9. Client/server ratios||9.2. Invocation and the master map|
Copyright © 2002 O'Reilly & Associates. All rights reserved.