Managing NFS and NIS, 2nd Edition - Mike Eisler [124]
% showmount -e wahoo
/export1 (everyone)
/export2 honeymoon
/export3 honeymoon
% cd /net/wahoo
% ls -l
total 3
drwxrwxr-x 22 root staff 512 Aug 12 16:02 export1
drwxrwxr-x 8 root staff 512 Feb 18 1999 export2
drwxrwxr-x 9 root staff 512 Sep 8 16:19 export3
When the automounter has to mount a filesystem on /net, it sends a request to the server asking for all exported filesystems. The automounter sorts the filesystems by pathname length, ensuring that subdirectories of exported filesystems appear later in the list than their parents.[2] The original automounter would then mount each item in the sorted list.
The enhanced autofs automounter will lazily mount each exported filesystem as soon as a process does something significant such as changing its current working directory to an exported filesystem:
% cd /net/wahoo
% ls -l
total 3
dr-xr-xr-x 1 root root 1 Sep 28 14:54 export1
dr-xr-xr-x 1 root root 1 Sep 28 14:54 export2
dr-xr-xr-x 1 root root 1 Sep 28 14:54 export3
% cd export1
% cd ..
% ls -l
total 3
drwxrwxr-x 22 root root 512 Aug 12 16:02 export1
dr-xr-xr-x 1 root root 1 Sep 28 14:54 export2
dr-xr-xr-x 1 root root 1 Sep 28 14:54 export3
The act of doing the cd export1causes the automounter to perform an NFS mount over the /net/wahoo/export1 autofs vnode. Thus, users cannot casually force the client to mount each filesystem unless they do something like:
% ls /net/wahoo/*
This command invocation tells ls to read each directory of each exported filesystem of wahoo. The autofs filesystem considers an invocation of its readdir entry point to be a significant operation worthy of triggering an NFS mount.
There are a number of caveats for using the -hosts map with automounters that don't support lazy mounting of hierarchies:
By including the entire hosts database, the hosts map references servers that are both local and on remote networks; a casual reference to a remote server causes an NFS mount to occur through a router or gateway.
If the server itself is slow, or has a large number of filesystems (diskless client servers), then the -hosts map has a definite performance impact.
Unmounts of the filesystems are done from the bottom up, in the reverse order of the mounts. If a higher-level mount point is busy, then an unmount of the entire hierarchy fails. When the automounter fails to unmount a higher-level mount point, it must remount the filesystems it just unmounted. It walks back down the hierarchy from the busy mount point, mounting each filesystem. The remote server's filesystems are mounted on an all-or-nothing basis.
Earlier in this section, we said that the "most widely used hierarchical mount is the builtin -hosts map." If you are not careful, it can be the most widely used map, period. The reason why this is not good is that -hosts is location-dependent. Once your users get used to accessing resources like /net/wahoo/tools, instead of accessing /tools, it becomes difficult to move the resource to a different physical location. It is best to discourage use of /net. One way to do so is to respond rapidly to requests to modify existing maps, or add new maps, and also, bury the physical location several directories deep on the server that holds the resource. Users will prefer pathnames like /tools/debugger over /net/wahoo/export/software/tools/debugger.
These caveats don't apply to the enhanced autofs automounter. However, by default it does support browsing. Thus a new caveat is that if a network has lots of hosts, then users that do:
% ls /net
will trigger lots of network traffic as the automounter gets the list of hosts from NIS. Thus, you should use the -nobrowse option on the -hosts map.
* * *
Tip
Users sometimes complain that they cannot see a new filesystem exported from a server. This is because a /net mount from the server was in effect before the filesystem was exported, and the automounter has to timeout the mount before unmounting and remounting. Rather than waiting for