amdref.texinfo

早期freebsd实现

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.

@node     Operational Principles, Mounting a Volume, Volume Binding, Overview
@comment  node-name,  next,  previous,  up
@section Operational Principles
@cindex Operational principles

@i{Amd} operates by introducing new mount points into the namespace.
These are called @dfn{automount} points.  The kernel sees these
automount points as NFS filesystems being served by @i{Amd}.  Having
attached itself to the namespace, @i{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 @dfn{lookup} call is received @i{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, @i{Amd} consults a configuration
@dfn{mount-map} corresponding to the automount point.  @i{Amd} then
makes a runtime decision on what and where to mount a filesystem based
on the information obtained from the map.

@i{Amd} does not implement all the NFS requests; only those relevant
to name binding such as @dfn{lookup}, @dfn{readlink} and @dfn{readdir}.
Some other calls are also implemented but most simply return an error
code; for example @dfn{mkdir} always returns ``read-only filesystem''.

@node     Mounting a Volume, Automatic Unmounting, Operational Principles, Overview
@comment  node-name,  next,  previous,  up
@section Mounting a Volume
@cindex Mounting a volume
@cindex Location lists
@cindex Alternate locations
@cindex Mount retries
@cindex Background mounts

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

@display
location1  location2  @dots{}  locationN
@end display

@i{Amd} examines each location in turn.  Each location may contain
@dfn{selectors} which control whether @i{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.

@i{Amd} attempts to mount the filesystem described by each remaining
location until a mount succeeds or @i{Amd} can no longer proceed.  The
latter can occur in three ways:

@itemize @bullet
@item
If none of the locations could be used, or if all of the locations
caused an error, then the last error is returned.

@item
If a location could be used but was being mounted in the background then
@i{Amd} marks that mount as being ``in progress'' and continues with
the next request; no reply is sent to the kernel.

@item
Lastly, one or more of the mounts may have been @dfn{deferred}.  A mount
is deferred if extra information is required before the mount can
proceed.  When the information becomes available the mount will take
place, but in the mean time no reply is sent to the kernel.  If the
mount is deferred, @i{Amd} continues to try any remaining locations.
@end itemize

Once a volume has been mounted, @i{Amd} establishes a @dfn{volume
mapping} which is used to satisfy subsequent requests.@refill

@node     Automatic Unmounting, Keep-alives, Mounting a Volume, Overview
@comment  node-name,  next,  previous,  up
@section Automatic Unmounting

To avoid an ever increasing number of filesystem mounts, @i{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 (@pxref{-w
Option, -w}).  It is also possible to set this value on a per-mount
basis (@pxref{opts Option, opts, opts}).@refill

Filesystems can be forcefully timed out using the @i{Amq} command.
@xref{Run-time Administration}.

@node     Keep-alives, Non-blocking Operation, Automatic Unmounting, Overview
@comment  node-name,  next,  previous,  up
@section Keep-alives
@cindex Keep-alives
@cindex Server crashes
@cindex NFS ping

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 recognised when an
NFS server crashes and the behaviour observed on client machines is that
more and more processes hang.  In order to provide the possibility of
recovery, @i{Amd} implements a @dfn{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.  @i{Amd} does this by sending RPC requests to the
servers' NFS @code{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 @i{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.

@c @i{Amd} keeps track of which servers are up and which are down.
@c It does this by sending RPC requests to the servers' NFS {\sc NullProc} and
@c checking whether a reply is returned.  If no replies are received after a
@c short period, @i{Amd} marks the fileserver @dfn{down}.
@c RPC requests continue to be sent so that it will notice when a fileserver
@c comes back up.
@c ICMP echo packets \cite{rfc:icmp} are not used because it is the availability
@c of the NFS service that is important, not the existence of a base kernel.
@c Whenever a reference to a fileserver which is down is made via @i{Amd}, an alternate
@c filesystem is mounted if one is available.
@c
Although this action does not protect user files, which are unique on
the network, or processes which do not access files via @i{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.
@c
@c With a suitable combination of filesystem management and mount-maps,
@c machines can be protected against most server downtime.  This can be
@c enhanced by allocating boot-servers dynamically which allows a diskless
@c workstation to be quickly restarted if necessary.  Once the root filesystem
@c is mounted, @i{Amd} can be started and allowed to mount the remainder of
@c the filesystem from whichever fileservers are available.

@node     Non-blocking Operation, , Keep-alives, Overview
@comment  node-name,  next,  previous,  up
@section Non-blocking Operation
@cindex Non-blocking operation
@cindex Multiple-threaded server
@cindex RPC retries

Since there is only one instance of @i{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.  @i{Amd} goes to great
lengths to ensure that it does not block in a system call.  As a last
resort @i{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
@i{Amd}'s task scheduler.  This library is also used to implement NFS
keep-alives (@pxref{Keep-alives}).

Whenever a mount is deferred or backgrounded, @i{Amd} must wait for it
to complete before replying to the kernel.  However, this would cause
@i{Amd} to block waiting for a reply to be constructed.  Rather than do
this, @i{Amd} simply @dfn{drops} the call under the assumption that the
kernel RPC mechanism will automatically retry the request.

@node     Supported Platforms, Mount Maps, Overview, Top
@comment  node-name,  next,  previous,  up
@chapter Supported Platforms

@i{Amd} has been ported to a wide variety of machines and operating systems.
The table below lists those platforms supported by the current release.

@menu
* Supported Operating Systems::
* Supported Machine Architectures::
@end menu

@node     Supported Operating Systems, Supported Machine Architectures, Supported Platforms, Supported Platforms
@comment  node-name,  next,  previous,  up
@section Supported Operating Systems
@cindex Operating system names
@cindex Operating systems supported by Amd
@cindex Supported operating systems

The following operating systems are currently supported by @i{Amd}.
@i{Amd}'s conventional name for each system is given.

@table @code
@item acis43
4.3 BSD for IBM RT.  Contributed by Jan-Simon Pendry @t{<jsp@@doc.ic.ac.uk>}
@item aix3
AIX 3.1.  Contributed by Jan-Simon Pendry @t{<jsp@@doc.ic.ac.uk>}
@item aux
System V for Mac-II.  Contributed by Julian Onions @t{<jpo@@cs.nott.ac.uk>}
@item bsd44
4.4 BSD.  Contributed by Jan-Simon Pendry @t{<jsp@@doc.ic.ac.uk>}
@item concentrix
Concentrix 5.0.  Contributed by Sjoerd Mullender @t{<sjoerd@@cwi.nl>}
@item convex
Convex OS 7.1.  Contributed by Eitan Mizrotsky @t{<eitan@@shumuji.ac.il>}
@item dgux
Data General DG/UX.  Contributed by Mark Davies @t{<mark@@comp.vuw.ac.nz>}
@item fpx4
Celerity FPX 4.1/2.  Contributed by Stephen Pope @t{<scp@@grizzly.acl.lanl.gov>}
@item hcx
Harris HCX/UX.  Contributed by Chris Metcalf @t{<metcalf@@masala.lcs.mit.edu>}
@item hlh42
HLH OTS 1.@i{x} (4.2 BSD).  Contributed by Jan-Simon Pendry @t{<jsp@@doc.ic.ac.uk>}
@item hpux
HP-UX 6.@i{x} or 7.0.  Contributed by Jan-Simon Pendry @t{<jsp@@doc.ic.ac.uk>}
@item irix
SGI Irix.  Contributed by Scott R. Presnell @t{<srp@@cgl.ucsf.edu>}
@item next
Mach for NeXT.  Contributed by Bill Trost @t{<trost%reed@@cse.ogi.edu>}
@item pyrOSx
Pyramid OSx.  Contributed by Stefan Petri @t{<petri@@tubsibr.UUCP>}
@item riscix
Acorn RISC iX.  Contributed by Piete Brooks @t{<pb@@cam.cl.ac.uk>}
@item sos3
SunOS 3.4 & 3.5.  Contributed by Jan-Simon Pendry @t{<jsp@@doc.ic.ac.uk>}
@item sos4
SunOS 4.@i{x}.  Contributed by Jan-Simon Pendry @t{<jsp@@doc.ic.ac.uk>}
@item u2_2
Ultrix 2.2.  Contributed by Piete Brooks @t{<pb@@cam.cl.ac.uk>}
@item u3_0
Ultrix 3.  Contributed by Piete Brooks @t{<pb@@cam.cl.ac.uk>}
@item u4_0
Ultrix 4.0.  Contributed by Chris Lindblad @t{<cjl@@ai.mit.edu>}
@item umax43
Umax 4.3 BSD.  Contributed by Sjoerd Mullender @t{<sjoerd@@cwi.nl>}
@item utek
Utek 4.0.  Contributed by Bill Trost @t{<trost%reed@@cse.ogi.edu>}
@item xinu43
mt Xinu MORE/bsd.  Contributed by Jan-Simon Pendry @t{<jsp@@doc.ic.ac.uk>}
@end table

@node     Supported Machine Architectures, , Supported Operating Systems, Supported Platforms
@comment  node-name,  next,  previous,  up
@section Supported Machine Architectures
@cindex Supported machine architectures
@cindex Machine architecture names
@cindex Machine architectures supported by Amd

@table @code
@item alliant
Alliant FX/4
@item arm
Acorn ARM
@item aviion
Data General AViiON
@item encore
Encore
@item fps500
FPS Model 500
@item hp9000
HP 9000/300 family
@item hp9k8
HP 9000/800 family
@item ibm032
IBM RT
@item ibm6000
IBM RISC System/6000
@item iris4d
SGI Iris 4D
@item macII
Apple Mac II
@item mips
MIPS RISC
@item multimax
Encore Multimax
@item orion105
HLH Orion 1/05
@item sun3
Sun-3 family
@item sun4
Sun-4 family
@item tahoe
Tahoe family
@item vax
DEC Vax
@end table

@node     Mount Maps, Amd Command Line Options, Supported Platforms, Top
@comment  node-name,  next,  previous,  up
@chapter Mount Maps
@cindex Mount maps
@cindex Automounter configuration maps
@cindex Mount information

@i{Amd} has no built-in knowledge of machines or filesystems.
External @dfn{mount-maps} are used to provide the required information.
Specifically, @i{Amd} needs to know when and under what conditions it
should mount filesystems.

The map entry corresponding to the requested name contains a list of
possible locations from which to resolve the request.  Each location
specifies filesystem type, information required by that filesystem (for
example the block special device in the case of UFS), and some
information describing where to mount the filesystem (@pxref{fs Option}).  A
location may also contain @dfn{selectors} (@pxref{Selectors}).@refill

@menu
* Map Types::