Managing NFS and NIS, 2nd Edition - Mike Eisler [109]
The automounter maps may be maintained using NIS, streamlining the administration of mount tables for all hosts in the network the same way NIS streamlines user account information.
Your exposure to hanging a process when an NFS server crashes is greatly reduced. The automounter unmounts all filesystems that are not in use, removing dependencies on fileservers that are not currently referenced by the client.
The automounter extends the basic NFS mount protocol to find the "nearest server" for replicated, read-only filesystems. The NFS server that is closest to the client — going through the fewest number of bridges and routers — will handle the mount request. Distributing client load in this manner reduces the load on the more heavily used network hardware.
In a large and dynamic NFS environment, it is difficult to keep the vfstab file on each machine up-to-date. Doing so requires creating mount points and usually hand-editing configuration files; automatic distribution of vfstab files is made difficult by the large number of host-specific entries in each. As you add new software packages or filesystems on the network, you usually have to edit every vfstab file. Using the automounter, you change one NIS map and allow the automounter to provide the new mount point information on all NIS clients.
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.