Managing NFS and NIS, 2nd Edition - Mike Eisler [125]
* * *
Hierarchical mounts in non -hosts maps
Let's return to our /tools example. Recall that /tools has:
/tools/deskset
/tools/sting
/tools/news
/tools/bugview
and is an indirect automounter map for the /tools directory, called auto_tools:
deskset -ro,intr mahimahi:/tools2/deskset
sting mahimahi:/tools2/sting
news thud:/tools3/news
bugview jetstar:/usr/bugview
/tools/deskset contains several subdirectories, one of which is wonderworks-v1.0. You recently get a Version 2.0 of Wonderworks, and you find that it requires more disk space than what mahimahi:/tools2/deskset has available. You have several choices here:
Create a new map entry into auto_tools called deskset2 for the new version of wonderworks. The problem with this is that your users expect to look in /tools/deskset, and not /tools/deskset2 for the desktop productivity tools.
Move the deskset directory from mahimahi to a server with a large partition. The problem is that this will impact existing users that have mahimahi:/tools2/deskset mounted.
Create a hierarchical mount for the deskset map entry such that /tools/deskset/wonderworks-v2.0 is mounted from somewhere else. This solution has none of the disadvantages of the previous choices.
To do the last choice requires the following steps:
Create a mount point for wonderworks-v2.0 on server mahimahi: On mahimahi:
# mkdir /tools/deskset/wonderworks-v2.0
Create a directory on another server (e.g., wahoo:/export/tools/deskset/wonderworks-v2.0) with sufficient disk space, and copy the wonderworks-v2.0 package to it. If necessary, export the directory via a new entry in /etc/dfs/dfstab and the shareall command.
Change the deskset entry in the auto_tools map to: deskset / -ro,intr mahimahi:/tools2/deskset \
/wonderworks-v2.0
-ro,intr
mahimahi:/tools2/deskset
Now when the user accesses /tools/deskset, he or she will be able reference both /tools/wonderworks-v1.0 and /tools/wonderworks-v1.0.
As the example suggests, the syntax of a hierarchical mount's map entry is:
key-name subdirectory1 [ -mount-options ] server-filesystem-1 [ subdirectory2 [ -mount-options ] server-filesystem-2 ] ...
where a server-filesystem is one of:
server_name:pathname
server_name-i:pathname-i,server_name-ii:pathname-ii [,...]
server_name-i,server_name-ii [,...]:pathname
Conversion of direct maps
Direct mounts are useful for handling nonuniform naming schemes, but they may cause a number of performance problems if several direct mount points are included in a directory that is frequently searched. You can usually get better performance out of the automounter by converting direct maps into indirect maps. Instead of putting direct map mount points in the client filesystem, create symbolic links that point to a staging area managed by an indirect map.
Again, an example helps to explain the conversion process. Consider replacing a direct map for /usr/local with an indirect map auto_stage. To convert the direct map into an indirect map, we first create a symbolic link /usr/local that points to a staging area that we'll let the automounter manage:
Original direct map
/usr/local mahimahi:/local/$ARCH
# ln -s /stage/local /usr/local
New entry in auto_master map
/stage auto_stage -ro
New indirect map auto_stage containing
local -ro mahimahi:/local/$ARCH
Note that /usr/local didn't exist before we made the link, since it was managed by the automounter. Also, we don't have to create the /stage staging directory, since it is an indirect map mount point.
The symbolic link points to a subdirectory of the mount point managed by the indirect map auto_stage.