Search

AMD&mdash;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.

Why Use AMD?

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.

How AMD Works

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.

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.

Setting Up AMD

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.

Running AMD

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.

NFS Considerations

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.

How to Get AMD

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.

Matthew Crosby
is a system administrator and
student at the University of Colorado, Boulder. He has administered
practically every system in existence, and has used Linux since the
early .9* days. He can be reached via e-mail at
crosby@nordsieck.cs.colorado.edu.