AMD—AutoMount Daemon

The standard protocol for sharing files between Linux boxes is the Network File System (NFS). This protocol, which originated with Sun in the mid 80s, does the job, but it has many deficiencies that can cause trouble for a systems administrator. Though there are alternatives, such as the Andrew File System (AFS) that are much nicer, most of us are stuck with NFS at this time—it is standard, available on every platform under the sun and free. Fortunately, the program AMD (AutoMount Daemon) exists to make living with NFS much easier.

AMD is an automounter—i.e., it maintains a cache of mounted file systems. At a minimum, AMD should be used wherever you use a normal NFS mount, since AMD makes your network more reliable. Because of the stateless design of NFS, any process trying to access data on an NFS partition will blocked if the partition’s server goes down. AMD improves the situation by keeping track of which machines are down and which are inaccessible. Since AMD doesn’t mount every partition immediately or keep them mounted, as does NFS, you save overhead that otherwise would be used for kernel and network traffic from the unused partitions, and thus improve machine performance.

Configuration and administration become much easier with AMD. Instead of requiring a different fstab file on each host, you can have a single, centrally maintained AMD map which can be distributed as a file with rdist or NIS maps or even Hesiod. As an example, we have over 100 machines with one centrally maintained AMD map. One map file is certainly easier to edit than 100.

Another convenient feature of AMD is dynamic maps that change depending on any number of criteria. A single map can point to multiple places, allowing you to do operations unavailable with normal NFS. For instance, if you have multiple replicated servers, you can set up a map so that if one server goes down, AMD will automatically mount files using one of the others.

AMD operates by mimicking an NFS server. When a file is accessed, AMD uses its map to decide where that file actually resides. It then mounts that partition, if necessary, using regular NFS, and mimics a symlink to the actual location. All AMD actions are done transparently, so that from the user’s point of view she is simply accessing a regular Unix symlink that points to a regular user’s file. AMD maintains its NFS mounts beneath a temporary directory, by default called “a”, a name choice that can cause problems. For example, the actual physical path of the directory /home/crosby is /a/home/crosby, but /a/home/crosby exists only if someone has recently accessed /home/crosby (or some other path on the same partition). Therefore, users should never explicitly access files through /a.

Diagram 1 demonstrates the three types of mounts involved: the native partition, the AMD pseudo partition and the behind-the-scenes NFS partition.

        ..................
        .  NFS Partition .
  \-+-a---home           .
    |   .....^............
    +-bin    :
    |        :
    |.........
    |.  AMD  .
    +-home   .
     .........

AMD does a few other things behind the scenes to keep operations healthy. First of all, it sends out rpc requests at regular intervals to all the servers it knows to see if they are alive. If one isn’t, AMD will not try to mount it. This checking also allows AMD to offer access to replicated file systems; that is, you can set up multiple redundant servers, and if one goes down, AMD will try to mount another one.

To use AMD, you must first of all build one or more AMD maps. These maps are the configuration files that tell AMD exactly what to do. Many tasks can be done from an AMD map, and documenting them all would take more than one article. Listing 1 provides a sample AMD map with some common tasks, and with comments under each entry to explain it. In general, a map consists of two fields: the name, which is translated to the path name underneath the AMD mount point, and the options, which specify what to do with this path name.

I have merely touched the surface of AMD features in Listing 1. The uses of AMD are almost endless—as the man page says, “A weird imagination is most useful to gain full advantage of all the features.” The documentation that comes with the package gives complete instructions for writing a map.

Listing 1. Example AMD Map

/defaults       opts:nosuid,nodev

#
# This statement specifies the defaults; any
# variables set here apply to all entries
# unless overridden. I simply set two NFS
# options:
# nosuid = don't allow suid programs
# nodev  = don't allow device files
#
doc   type:=nfs;rhost:=doc-server; \
                   rfs:=/usr/local/docs

# This statement is one of the simplest volume
# specifications. It assigns a location
# /u/doc, which maps to the directory
# /usr/local/docs on the machine
# doc-server.

home/crosby    host==cia;type:=link;fs:=/a/home/crosby \
                  host!=cia;type:=nfs;rhost:=cia;rfs:=/a/home/crosby

# This entry is slightly more complicated.
# It specifies information about my home
# directory, on the machine cia. Basically,
# it accomplishes the same thing as the
# preceding entry, except that when the machine
# in question is the host itself it simply acts
# as a symlink to the location rather then
# mounting it; thus, the performance problems
# of a machine mounting off of itself are
# avoided while at the same time single map
# for all hosts is allowed.

# Note that the directory is UFS mounted in the
# same place that AMD would NFS mount it,
# under /a.

tools   arch==pa-risc;wire==net1;type:=nfs;  \
                rhost:=nag;rfs:=/tools \
   arch==pa-risc;wire==net2;type:=nfs; \
                rhost:=nagina;rfs:=/tools \
   arch==dec-mips;wire==net1;type:=nfs; \
                rhost:=frisbee;rfs:=/tools \
   arch==dec-mips;wire==net2;type:=nfs; \
                rhost:=aerobie;rfs:=/tools \
   arch==i386;wire==net1;type:=nfs; \
                rhost:=hazelrah;rfs:=/tools \
   arch==i386;wire==net2;type:=nfs; \
                rhost:=pipkin;rfs:=/tools \

# This entry is quite complicated. It has a mount
# point that varies depending on which network the
# machine resides (the "wire" variable, which can
# take symbolic network names or ip addresses) and
# which architecture (HP, # PC/linux, PC/solaris, or
# DEC) applies to the machine. By setting the
# mount point this way, the users know they can
# go to /u/tools and get the correct binaries for
# the current architecture mounted off the local
# network--regardless of which machine
# they are using

home/*   -opts:=nosuid \
        hosttype:=nfs;rhost:=${key};rfs:=/home/${key}

# This statement is a wildcard map--any entry
# /home/whatever is mapped to machine whatever.
# Having a wild card map is very useful: I can now
# have hundreds of machines with home directories,
# and still have only one map entry. And to add a
# new one, I simply have to add the machine and
# export it--I don't have to modify the map.
#
# This statement also shows how to designate entry
# specific NFS options; I don't want to allow
# suid programs in home directories, so I turn it
# off (-opts:=nosuid).
<\n>
 data type:=nfs;rfs:=/data rhost:=server1 \
        rhost:=server2 rhost:=server3

# This statement sets up a replicated server.
# If we have important data, we want to make
# sure it will be available even if a server
# crashes. This data ia replicated over three
# servers, and AMD will mount from whichever one
# it can.

To run AMD, you simply type amd at the prompt, providing the mount point(s) amd the map(s) on the command line. For example, if the map in listing 1 is named /etc/map.main, and a map named /etc/map.silly also exists, to execute AMD you would type:

amd /u /etc/map.main /silly /etc/map.silly

It is a good idea to include this statement in your rc files.

A number of options are available for the amd command. Two useful options are the ability to specify the NFS mount points and the timeout period. The program amq helps control AMD. For example, amq can force AMD to unmount a file system and to flush the cache (useful when debugging NFS problems). The man page for amq provides a complete description of all its capabilities.

Because AMD is just a front end to regular NFS, you have to worry about the same issues that you would when running NFS alone—you must ensure that exports and their options are correct. Explaining NFS is beyond the scope of this article; however, if you are unfamiliar with the basics of NFS, see the NFS Resources box on page FIXME.

Binaries and patches to port AMD to Linux may be obtained from sunsite and other sources (see sidebar). AMD has stayed relatively stable and bug free in the last few years; development is no longer active. AMD comes with excellent documentation.

AMDResources

NFS Resources