Amd maintains a cache of mounted filesystems. Filesystems are demand-mounted when they are first referenced, and unmounted after a period of inactivity. Amd may be used as a replacement for Sun's automount(8) program. It contains no proprietary source code and has been ported to numerous flavors of Unix. See section 2 Supported Platforms.
Amd was designed as the basis for experimenting with filesystem layout and management. Although Amd has many direct applications it is loaded with additional features which have little practical use. At some point the infrequently used components may be removed to streamline the production system.
The fundamental concept behind Amd is the ability to separate the name used to refer to a file from the name used to refer to its physical storage location. This allows the same files to be accessed with the same name regardless of where in the network the name is used. This is very different from placing `/n/hostname' in front of the pathname since that includes location dependent information which may change if files are moved to another machine.
By placing the required mappings in a centrally administered database, filesystems can be re-organized without requiring changes to configuration files, shell scripts and so on.
Amd views the world as a set of fileservers, each containing one or more filesystems where each filesystem contains one or more volumes. Here the term volume is used to refer to a coherent set of files such as a user's home directory or a TeX distribution.
In order to access the contents of a volume, Amd must be told in which filesystem the volume resides and which host owns the filesystem. By default the host is assumed to be local and the volume is assumed to be the entire filesystem. If a filesystem contains more than one volume, then a sublink is used to refer to the sub-directory within the filesystem where the volume can be found.
Volume names are defined to be unique across the entire network. A volume name is the pathname to the volume's root as known by the users of that volume. Since this name uniquely identifies the volume contents, all volumes can be named and accessed from each host, subject to administrative controls.
Volumes may be replicated or duplicated. Replicated volumes contain identical copies of the same data and reside at two or more locations in the network. Each of the replicated volumes can be used interchangeably. Duplicated volumes each have the same name but contain different, though functionally identical, data. For example, `/vol/tex' might be the name of a TeX distribution which varied for each machine architecture.
Amd provides facilities to take advantage of both replicated and duplicated volumes. Configuration options allow a single set of configuration data to be shared across an entire network by taking advantage of replicated and duplicated volumes.
Amd can take advantage of replacement volumes by mounting them as required should an active fileserver become unavailable.
Unix implements a namespace of hierarchically mounted filesystems. Two forms of binding between names and files are provided. A hard link completes the binding when the name is added to the filesystem. A soft link delays the binding until the name is accessed. An automounter adds a further form in which the binding of name to filesystem is delayed until the name is accessed.
The target volume, in its general form, is a tuple (host, filesystem, sublink) which can be used to name the physical location of any volume in the network.
When a target is referenced, Amd ignores the sublink element and determines whether the required filesystem is already mounted. This is done by computing the local mount point for the filesystem and checking for an existing filesystem mounted at the same place. If such a filesystem already exists then it is assumed to be functionally identical to the target filesystem. By default there is a one-to-one mapping between the pair (host, filesystem) and the local mount point so this assumption is valid.
Amd operates by introducing new mount points into the namespace. These are called automount points. The kernel sees these automount points as NFS filesystems being served by Amd. Having attached itself to the namespace, Amd is now able to control the view the rest of the system has of those mount points. RPC calls are received from the kernel one at a time.
When a lookup call is received Amd checks whether the name is already known. If it is not, the required volume is mounted. A symbolic link pointing to the volume root is then returned. Once the symbolic link is returned, the kernel will send all other requests direct to the mounted filesystem.
If a volume is not yet mounted, Amd consults a configuration mount-map corresponding to the automount point. Amd then makes a runtime decision on what and where to mount a filesystem based on the information obtained from the map.
Amd does not implement all the NFS requests; only those relevant to name binding such as lookup, readlink and readdir. Some other calls are also implemented but most simply return an error code; for example mkdir always returns "read-only filesystem".
Each automount point has a corresponding mount map. The mount map contains a list of key--value pairs. The key is the name of the volume to be mounted. The value is a list of locations describing where the filesystem is stored in the network. In the source for the map the value would look like
location1 location2 ... locationN
Amd examines each location in turn. Each location may contain selectors which control whether Amd can use that location. For example, the location may be restricted to use by certain hosts. Those locations which cannot be used are ignored.
Amd attempts to mount the filesystem described by each remaining location until a mount succeeds or Amd can no longer proceed. The latter can occur in three ways:
Once a volume has been mounted, Amd establishes a volume mapping which is used to satisfy subsequent requests.
To avoid an ever increasing number of filesystem mounts, Amd removes
volume mappings which have not been used recently. A time-to-live
interval is associated with each mapping and when that expires the
mapping is removed. When the last reference to a filesystem is removed,
that filesystem is unmounted. If the unmount fails, for example the
filesystem is still busy, the mapping is re-instated and its
time-to-live interval is extended. The global default for this grace
period is controlled by the
-w command-line option (see section 4.12
-w wait-timeout) or the amd.conf parameter `dismount_interval'
(see section 6.5.6 dismount_interval Parameter). It is also possible to set this
value on a per-mount basis (see section 220.127.116.11 opts Option).
Filesystems can be forcefully timed out using the Amq command. See section 7 Run-time Administration.
Use of some filesystem types requires the presence of a server on another machine. If a machine crashes then it is of no concern to processes on that machine that the filesystem is unavailable. However, to processes on a remote host using that machine as a fileserver this event is important. This situation is most widely recognized when an NFS server crashes and the behavior observed on client machines is that more and more processes hang. In order to provide the possibility of recovery, Amd implements a keep-alive interval timer for some filesystem types. Currently only NFS makes use of this service.
The basis of the NFS keep-alive implementation is the observation that most sites maintain replicated copies of common system data such as manual pages, most or all programs, system source code and so on. If one of those servers goes down it would be reasonable to mount one of the others as a replacement.
The first part of the process is to keep track of which fileservers are
up and which are down. Amd does this by sending RPC requests to the
NullProc and checking whether a reply is returned.
While the server state is uncertain the requests are re-transmitted at
three second intervals and if no reply is received after four attempts
the server is marked down. If a reply is received the fileserver is
marked up and stays in that state for 30 seconds at which time another
NFS ping is sent.
Once a fileserver is marked down, requests continue to be sent every 30 seconds in order to determine when the fileserver comes back up. During this time any reference through Amd to the filesystems on that server fail with the error "Operation would block". If a replacement volume is available then it will be mounted, otherwise the error is returned to the user.
Although this action does not protect user files, which are unique on the network, or processes which do not access files via Amd or already have open files on the hung filesystem, it can prevent most new processes from hanging.
By default, fileserver state is not maintained for NFS/TCP mounts. The remote fileserver is always assumed to be up.
Since there is only one instance of Amd for each automount point, and usually only one instance on each machine, it is important that it is always available to service kernel calls. Amd goes to great lengths to ensure that it does not block in a system call. As a last resort Amd will fork before it attempts a system call that may block indefinitely, such as mounting an NFS filesystem. Other tasks such as obtaining filehandle information for an NFS filesystem, are done using a purpose built non-blocking RPC library which is integrated with Amd's task scheduler. This library is also used to implement NFS keep-alives (see section 1.8 Keep-alives).
Whenever a mount is deferred or backgrounded, Amd must wait for it to complete before replying to the kernel. However, this would cause Amd to block waiting for a reply to be constructed. Rather than do this, Amd simply drops the call under the assumption that the kernel RPC mechanism will automatically retry the request.
Go to the first, previous, next, last section, table of contents.