• Choose a category
• All
• Classic-Fiction

HOST

output of uname -n

OSNAME

output of uname -s

OSREL

output of uname -r

OSVERS

output of uname -v

NATISA

output of isainfo -n

If you can use builtin variables, then you should use them instead of specifying the value of variables with the -D option to automountd. The reason is that editing the script that starts the automountd process is going to be very tedious as your site grows. So in the previous section, we had the example:

Automounter daemon invocation

/usr/lib/autofs/automountd -D MACHTYPE=`/usr/bin/uname -m'

Don't do that! Leave the automountd parameters alone, and instead have the map use the $ARCH builtin, instead of the custom $MACHTYPE variable:

auto_direct map

/usr/local/bin -ro mahimahi:/local/bin.$ARCH

Advanced map tricks

The automounter has several features that complement the "normal" NFS mount options. It can mount replicated filesystems from one of several potential servers, and it can perform hierarchical mounts of all of a server's directories when any one of them is referenced. This section starts with a discussion of these advanced automounter features, then explains how to get better performance out of the automounter by converting direct map entries into indirect maps and by using the automounter's subdirectory mount feature.

Replicated servers

Multiple location support in the automounter implements a simple network load-balancing scheme for replicated filesystems. At first glance, this seems to be a bit of overkill; after all, you don't need or want replication for read-write filesystems. However, serving large, read-only filesystems such as the manpages may add to an NFS server's request load. Having multiple servers share this load improves performance by reducing the total load placed on the most heavily used servers. Ideally, you want clients that are "close" to each server to mount its filesystems, reducing the amount of traffic that must go through bridges or routers.

For example, if you have four NFS servers that each export the manpages, the best client mounting scheme is probably not to have one-quarter of the clients mount /usr/man from each server. Instead, clients should mount the manpages from the server that is closest to them. Replicated filesystems are included in automounter maps simply by listing all possible servers in the map:

/usr/man -ro wahoo:/usr/man mahimahi:/usr/man \

thud:/usr/man onaga:/usr/man

The backslash at the end of the first line continues this indirect map entry onto the next line. If more than one server:directory pair is listed in an automounter map, the automounter pings all servers by sending a request to the null procedure of all NFS servers. From the set that responds, the automounter picks one that is "closest" by comparing the address of the servers with that of the clients. Ties are broken by using the server that responded to the ping first. The selected server is used by the automounter to serve the mount point.

There is also an element of load balancing at work here: if one of the /usr/man servers is so heavily loaded with other NFS traffic that it cannot reply to the ping before another server on the same net, then the client will choose the other server to handle its mount request. Solaris 2.6 introduced the feature of client-side failover, which was discussed in Section 6.5. While it doesn't explicitly implement load balancing, if, after the mount, one server becomes overloaded enough, a client will find the server to be unresponsive and will dynamically switch to another server. Keep in mind the following:

If the ro mount option is not present, or if the soft option is present, client-side failover is not enabled, and in that situation, once a client performs a mount from a server, it continues to use that server until it unmounts the filesystem.

If the list of servers providing the filesystem changes, once the filesystem is mounted, with or without failover, the client cannot choose a different server before unmounting its first choice.

You can use the first-answer feature of replicated map