9.2. Invocation and the master mapNow 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 mapThe 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:
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:# Directory Map NFS Mount Options /tools /etc/auto_tools -ro /- /etc/auto_direct
In this example, we observe three things:# Directory Map NFS Mount Options /tools auto_tools -ro /- auto_direct
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:automount: nis
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 188.8.131.52, "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.+auto_master /net -hosts -nosuid,nobrowse /home auto_home -nobrowse /xfn -xfn
9.2.2. Command-line optionsThe autofs automounter is started during the boot sequence from the /etc/init.d/autofs script. The automounter consists of two programs:
184.108.40.206. Automount command-line options
220.127.116.11. Automountd command-line options
9.2.3. The null mapThe 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:
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./tools -null
9.2.4. Tuning timeout valuesWhen 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:
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.automount -t 3600
Copyright © 2002 O'Reilly & Associates. All rights reserved.