Managing NFS and NIS, 2nd Edition - Mike Eisler [123]
natasha -rw,hard boris:/export/home/boris \
boris-bb2:/export/home/boris \
boris-bb3:/export/home/boris \
boris-bb4:/export/home/boris
This would be an entry in the auto_home map. Since the server pathnames are the same, you can use a shorter form of the replicated map entry, putting all of the server names in a comma-separated list:
natasha -rw,hard boris,boris-bb2,boris-bb3,boris-bb4:/home/boris
The network interface on boris that is closest to the client will respond first, and each NFS client of boris will mount /home/natasha from the best network interface. Note that the replicated mount points don't refer to multiple filesystems, but rather multiple names for the same filesystem. The automounter just provides a neat way of managing all of them in a single place. Because /export/home/natasha is mounted read-write, client-side failover is not enabled. This is somewhat unfortunate since this is the one situation where client-side failover of a writable filesystem is safe: the filesystem is the same, because the physical host is the same. But the client has no way of knowing that.
When the automounter pings the remote servers, it's performing the equivalent of:
rpcinfo -u hostname nfs
for each listed server. If you see a larger number of null procedure calls than usual in the output of nfsstat on the NFS server, it might indicate that your automounter mounts of replicated filesystems are being performed repeatedly. The null calls do not require any disk accesses to service, but they can consume network bandwidth on the server; if the number of null calls becomes excessive it may be due to client machines continually mounting and unmounting replicated filesystems. Changing the value of the -t option to automount (as discussed previously in Section 9.2.4) reduces the frequency of mounting and unmounting.
You can also examine the /etc/rmtab file on the server to see how frequently its clients are mounting and unmounting automounted filesystems. When a filesystem is mounted, an entry is added to the /etc/rmtab file. When it gets unmounted, the entry isn't deleted from the file — it is commented out by making the first character in the line a pound sign (#):
#epeche:/usr/share/man
#haos:/usr/share/man
#epeche:/usr/share/man
depeche:/usr/share/man
chaos:/usr/share/man
In this example, client depeche has mounted /usr/share/man three times, and client chaos has mounted that filesystem twice. This gives you client information to go along with the null NFS RPC counts provided by nfsstat — you can tell which clients have been repeatedly mounting and unmounting a filesystem. Watch the size of the /etc/rmtab file over time; if it grows regularly and contains multiple entries for the same clients and filesystems, then you may want to change the automounter timeout value on those clients.
Hierarchical mounts
In addition to handling multiple servers for the same filesystem, the automounter can mount multiple trees from the same server in a hierarchy of mount points. Hierarchical mounts are simply a special form of indirect maps.
The -hosts map
The most widely used hierarchical mount is the builtin -hosts map, which mounts all exported filesystems from a named host.
The -hosts map references only the hosts database; the map semantics are built into the automounter. It is usually mounted on /net indicating that it contains filesystems from the entire network. The following line would appear in the master map:
/net -hosts -nobrowse
Except when using the enhanced autofs automounter, a user can then force mounts