Managing NFS and NIS, 2nd Edition - Mike Eisler [118]
automount -t 3600
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.
Integration with NIS
If maps are maintained on each client machine, then the administrative benefits of using the automounter are lost; the burden of maintenance is shifted away from the vfstab file and onto the new map files. To solve the administrative problem, all three types of maps may be distributed using NIS.
To add an automounter map to the NIS database, insert a set of clauses for it in the NIS master server's Makefile in /var/yp:
In definition of target all:
all: passwd hosts ..... auto.tools
auto.tools: auto.tools.time
auto.tools.time: $(DIR)/auto_tools
-@if [ -f $(DIR)/auto_tools ]; then \
sed -e "/^#/d" -e s/#.*$$// $(DIR)/auto_tools | \
$(MAKEDBM) - /var/yp/$(DOM)/auto.tools;\
touch auto.tools.time; \
echo "updated auto.tools"; \
if [ ! $(NOPUSH) ]; then \
$(YPPUSH) auto.tools; \
echo "pushed auto.tools"; \
fi \
else \
echo "couldn't find $(DIR)/auto_tools"; \
fi
The new map name must be added to the list of targets built by default when make is issued with no arguments. A dependency linking the map name auto.tools to the timestamp file auto.tools.time is added, and the large section defines how to rebuild the map and the timestamp file from the map source file. The makefile actions strip out all lines beginning with a comment (#) marker, and strip comments from the ends of lines. The makedbm program builds an NIS map from the input file. The input file should not have blank lines in it.
The key in an automounter map becomes the NIS map key, and the mount options and server and directory names are the data values. Dumping a map with ypcat requires the -k option to match up map keys and server information:
% ypcat auto.tools
-ro,intr thud:/epubs/deskset
jetstar:/usr/Bugview
-ro,intr mahimahi:/tools2/deskset1.0
% ypcat -k auto.tools
sundesk -ro,intr thud:/epubs/deskset
bugview jetstar:/usr/Bugview
deskset -ro,intr mahimahi:/tools2/deskset1.0