UNIX System Administration Handbook - Evi Nemeth [299]
Dedicated NFS file servers have been around for more than a decade. They offer a host of potential advantages over the homebrew approach:
• They are optimized for file service and typically provide the best possible NFS performance.
• As storage requirements grow, they can scale smoothly to support terabytes of storage and hundreds of users.
• They are more reliable than UNIX boxes thanks to their simplified software, redundant hardware, and use of disk mirroring.
• They usually provide file service for both UNIX and Windows clients. Some even contain integral web and FTP servers.
• They are often easier to administer than UNIX file servers.
• They often provide backup and checkpoint facilities that are superior to those found on vanilla UNIX systems.
Of the current offerings, our favorites are those made by Network Appliance, Inc. (www.netapp.com). Their servers run the gamut from very small to very large, and their pricing is OK. Auspex and EMC are players in the high-end server market. They make good products, but be prepared for sticker shock and build up your tolerance for marketing buzzwords.7
17.6 AUTOMATIC MOUNTING
Mounting filesystems one at a time by listing them in /etc/fstab or /etc/vfstab introduces a number of problems in large networks. First, maintaining /etc/fstab on a few hundred machines can be tedious. Each one may be slightly different and thus require individual attention.
Second, if filesystems are mounted from many different hosts, chaos ensues when one of those servers crashes. Every command that stats the mount points will hang.
Third, when an important server crashes, it may cripple users by making important partitions like /usr/share/man unavailable. In this situation, it’s best if a copy of the partition can be mounted temporarily from a backup server.
An automount daemon mounts filesystems when they are referenced and unmounts them when they are no longer needed. This procedure minimizes the number of active mount points and is mostly transparent to users. With most automounters, it is also possible to supply a list of “replicated” (identical) filesystems so that the network can continue to function when a primary server becomes unavailable.
To implement this behind-the-scenes mounting and unmounting, the automounter mounts a virtual filesystem driver on the directories you’ve designated as locations for automatic mounting to occur. In the past, the automounter did this by posing as an NFS server, but this scheme suffers from several significant limitations and is rarely found on contemporary systems. These days, a kernel-resident filesystem driver called autofs is used.
Instead of mirroring an actual filesystem, an automounter “makes up” a filesystem hierarchy according to the specifications you list in its configuration file. When a user references a directory within the automounter’s virtual filesystem, the automounter intercepts the reference and mounts the actual filesystem the user is trying to reach. On systems that support autofs, the NFS filesystem is simply mounted within the autofs filesystem in normal UNIX fashion. Other systems may require mounting to occur in a separate directory that is then pointed to by symbolic links.
The idea of an automounter originally comes from Sun. Sun’s implementation is called automount and is shipped with most Sun-derived NFS clients. Red Hat supplies an automount designed to mimic Sun’s, though it is an independent implementation of the concept.
Prior to the autofs era, automount was plagued with bugs and design flaws and could not reliably be used on production systems. Current implementations are generally much better, though reviews are still somewhat mixed. Many people use it extensively with no problems; others still experience occasional hangs. Reliability no doubt varies by system and implementation.
amd, originally