Invocation and the master map (Managing NFS and NIS, 2nd Edition)

9.2. Invocation and the master map

Now that we've seen how the automounter manages NFS mount information in various maps, we'll look at how it chooses which maps to use and how it gets started. The key file that tells the automounter about map files and mount points is the master map, which is the default map read by the automounter if no other command-line options are specified. This covers the format and use of the master map, some command-line options, and some timeout tuning techniques.

9.2.1. The master map

The master map is the map of maps. When the automounter is started, it reads the master map from where the /etc/nsswitch.conf configuration file says to read it, as determined by the nsswitch.conf entry named automount:. Thedefault nsswitch.conf -- whether files, or NIS is used -- has files listed first. The master map file, /etc/auto_master, lists all direct and indirect maps and their associated directories. It consists of triplets of directory name, map name, and mount options to be used with that map. Suppose your /etc/auto_master file contains:

# Directory     Map                     NFS Mount Options 
/tools          /etc/auto_tools         -ro 
/-              /etc/auto_direct

The first entry is for the indirect map /etc/auto_tools; entries in this map are mounted read-only (due to the -ro option) under the /tools directory. The second line of the master file is for a direct map; because there is no directory for the automounter to manage, the place holder /- is used. Note that the master map format is different from other automounter maps in the following ways:

With the master maps, the mount options are in the third column, whereas regular automounter maps place the options in the second column.
The first column in a master map is always an absolute pathname that starts with a leading slash (/) and can have one or more additional slashes, whereas with indirect maps the first column is a map key that must not contain a slash.

The earlier example is somewhat limiting in that changes to the auto_tools or auto_direct map must be made by editing each /etc/auto_tools or /etc/auto_direct file on each NFS client. Instead, if we drop the /etc/ prefix, we can allow the maps to be maintained in NIS or files:

# Directory     Map             NFS Mount Options 
/tools          auto_tools         -ro 
/-              auto_direct

In this example, we observe three things:

Two map names -- auto_direct and auto_tools -- are used in place of the files pulled from /etc in the previous example.
The system decides to use NIS or files for auto_direct and auto_tools based on whether files or nis (or both) are specified in nsswitch.conf.
Even though the corresponding map names in NIS are auto_direct and auto_tools, the auto_master file uses a canonical name form, which uses underscores and not periods to separate the prefix auto from the unique suffix (direct or tools). The reason is that in some directory systems, such as NIS+, a period is a reserved character.

There is no requirement that the master map be maintained as a local file. Indeed you might find it easier if you configure your network's clients' nfsswitch.conf file to read all the maps, including the master map from NIS by setting automount: line in nsswitch.conf as:

automount: nis

This way you can exercise control over each client's namespace without having to reconfigure every client each time you want to add or delete a map from the master map. We will cover how the automounter maps are integrated into NIS later, in Section 9.3, "Integration with NIS".

The default master map is not going to appear as in the examples presented so far. The default Solaris /etc/auto_master file looks something like this:

+auto_master
/net            -hosts          -nosuid,nobrowse
/home           auto_home       -nobrowse
/xfn            -xfn

We will discuss the first entry, +auto_master in Section 9.3.1, "Mixing NIS and files in the same map". The second entry, /net, will be covered in Section 9.5.2.1, "The -hosts map". The third entry, /home, will be covered in Section 9.4.1, "Key substitutions".

The last entry, /xfn, is for the X/Open Federated Naming Standard (XFN), which is a now-deprecated standard for federating directory systems. Recall from Section 2.2, "Brief survey of common directory services" that there are lots of directory services. XFN represented an attempt to allow them all to seamlessly co-exist in a global namespace. The idea was to allow users in one DNS domain to browse or access information (such as files, printers, or calendars) from another domain, even if the naming system that organized the information did not easily support cross-domain operations (as is the case with NIS). Because it appears that the world will be unifying under LDAP, and because nsswitch.conf meets most of the requirements for directory service switching, XFN has been deprecated. While the /xfn entry persists to allow you to browse any NIS or files data represented in XFN, expect XFN and /xfn to disappear from future Solaris releases.

9.2.2. Command-line options

The autofs automounter is started during the boot sequence from the /etc/init.d/autofs script. The automounter consists of two programs:

automount: Used to initialize the automounter's mount points after it reads the master map.

automountd

Each program has several command-line options.

9.2.2.1. Automount command-line options

-t time

-v: If set, this option prints out any new autofs mounts or unmounts. The automount command will perform a mount for each new direct and indirect map, and will perform an unmount for each map no longer listed in the master map or any of its submaps.

9.2.2.2. Automountd command-line options

-T

Turns on NFS call tracing, so the user sees the expansion of NFS calls handled by the automounter. If this option is used for debugging, then the standard output and standard error of the automounter daemon should be redirected to a file from its invocation in /etc/init/autofs:

/usr/lib/autofs/automountd -T > /tmp/auto_nfscalls
2&1
Excerpt from /tmp/auto_nfscalls 
t8      LOOKUP REQUEST: Tue Sep 28 10:39:36 1999
t8        name=news[] map=auto.tools opts=intr,nosuid path=/tools direct=0
t8      LOOKUP REPLY    : status=0
t1      MOUNT REQUEST:   Tue Sep 28 10:39:36 1999
t1        name=news[] map=auto.tools opts=intr,nosuid path=/tools direct=0
t1      MOUNT REPLY    : status=0, AUTOFS_DONE

In this example, the automounter daemon was asked by autofs to look up the directory news. It returned a status structure indicating that the daemon is requesting an NFS mount. The autofs filesystem then asked the daemon to perform the NFS mount, and the automounter returned a successful status. The prefixes t8 and t1 indicate the thread in the automounter daemon that did the operation.

-v: Turns on a verbose mode that logs status messages to the console.

-n: Turns off browsing of indirect maps.

-D var=value

9.2.3. The null map

The automounter also has a map "white-out" feature, via the -null special map. It is used after a directory to effectively delete any map entry affecting that directory from the automounter's set of maps. It must precede the map entry being deleted. For example:

/tools -null

This feature is used to override auto_master or direct map entries that may have been inherited from an NIS map. If you need to make per-machine changes to the automounter maps, or if you need local control over a mount point managed by the automounter, white-out the conflicting map entry with the -null map.

9.2.4. Tuning timeout values

When a filesystem has remained quiescent for some time, it is a candidate for unmounting. If the filesystem is busy, the attempts to unmount it will fail until the last open files and directories are closed. If an unmount attempt fails, the automounter tries it again later. However, it is difficult for the automounter to know if the filesystem is in fact in use. The simplest way to find out is to attempt to unmount it. So every ten minutes (or the period specified with the -t flag to automount) the automounter attempts to unmount every mounted filesystem.

There are two situations in which increasing the default unmount timeout period improves performance of the automounter:

When client processes keep files open for more than ten minutes
When one or more processes requiring automounted filesystems run regularly, with periods greater than the default timeout

When the automounter attempts to unmount a filesystem, it either succeeds, or the one or more open files from one or more processes cause the umount( ) call to return EBUSY. If there are several filesystems used by processes that behave in this fashion, then the automounter wastes numerous umount( ) system calls. The cost isn't just the overhead of checking to see if a filesystem is in use. There are several caches that hold references on the filesystem that must be flushed. All this activity consumes CPU time, which can impact the performance of a system that is already under high load. Increasing the default unmount timeout period (using the -t option) to match the average filehandle lifetime reduces the overhead of using the automounter:

automount -t 3600

The timeout period is specified in seconds. The reduced number of mount operations comes at a cost of a longer binding to the NFS server. If the filesystem is mounted when the NFS server crashes, you will have lost the "working set" advantage of using the automounter -- your system hangs until the server recovers.

As mentioned earlier, regularly scheduled processes may require longer automounter timeout periods. Regularly scheduled processes include those run by cron and repetitive operations performed by interactive users, such as make runs done several times an hour during bug-fixing cycles. Each regularly scheduled process begins by causing a filesystem mount; a corresponding unmount is done sometime before its next invocation if the default timeout period is shorter than the time between invocations.

If the time between process instances is long, the overhead of these repetitive mount operations is negligible. However, a job that is run every ten minutes initiates a sequence of mount and unmount operations, adding to the overhead incurred by running the automounter. For interactive processes that run to completion in a minute or less, the time to complete the mount increases the response time of the system, and it is sure to elicit complaints. In both cases, system performance is improved by reducing the overhead of the automounter through a longer default unmount timeout period.

You may not want to use the automounter for filesystems that are mounted or accessed nearly constantly through the day. The mail spool, for example, might be better placed in each client's /etc/vfstab file because it will be in near-constant use on the client. Most other filesystems benefit from the streamlined NFS administration provided by the automounter. Using the automounter is simplified even further by managing the maps themselves with NIS.