Return to maps.tex CVS log

Up to [CSRG BSD Unix] / 43BSDReno / usr.sbin / amd / doc

BSD 4.3reno

% $Id: maps.tex,v 1.1.1.1 2018/04/24 16:12:57 root Exp $
%
% Copyright (c) 1989 Jan-Simon Pendry
% Copyright (c) 1989 Imperial College of Science, Technology & Medicine
% Copyright (c) 1989 The Regents of the University of California.
% All rights reserved.
%
% This code is derived from software contributed to Berkeley by
% Jan-Simon Pendry at Imperial College, London.
%
% Redistribution and use in source and binary forms are permitted provided
% that: (1) source distributions retain this entire copyright notice and
% comment, and (2) distributions including binaries display the following
% acknowledgement:  ``This product includes software developed by the
% University of California, Berkeley and its contributors'' in the
% documentation or other materials provided with the distribution and in
% all advertising materials mentioning features or use of this software.
% Neither the name of the University nor the names of its contributors may
% be used to endorse or promote products derived from this software without
% specific prior written permission.
% THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR IMPLIED
% WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF
% MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
%
%	@(#)maps.tex	5.1 (Berkeley) 7/19/90


\Chapter{Mount-maps}

\Amd\ has no built-in knowledge of machines or filesystems.
External {\em mount-maps} are used to provide the required information.
Specifically, \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 (\see \Ref{mount location}).
A location may also contain {\em selectors} (\see \Ref{selectors}).

\Section{Map Types}

A mount-map can be implemented as a regular file, an ndbm database
a YP map \cite{sun:yp} or via
the {\em Hesiod} \cite{mit:hesiod} name
server.
In addition, the password ``file'' can be used as a source of
map information.
%\footnote{In future, gdbm databases will also be supported.}
A mount-map name is a sequence of characters.
When an automount point is created a handle on the mount-map
is obtained.  If the the map name begins with the sequence
``{\tt hesiod.}''\ then the {\em Hesiod} name server will be used.
If the map name is the string ``{\tt /etc/passwd}'' then the password
``file'' will be used.
Otherwise the map name is referenced as a file,
then as an ndbm database by that name and then as a YP map.
As soon as a valid reference is found the map type is noted
for future use but any resources held are released, for example
any open file descriptors are closed.
The available map types are a configurable component of \amd\ and
can be displayed by running the command {\tt amd~-v}.

By default, \amd\ does not cache any data retrieved from a mount map.
This is a policy decision based on the observation that most workstations
have more available CPU time than spare memory.
However, on a multi-user service or larger workstation the faster
response provided by a cache can be preferable.  The \opt{cache}
option can be specified on automount points to alter the
caching behaviour (\see \Ref{auto-fs}).
Specifying {\tt cache:=mapdefault} selects a suitable default
cache mode depending on the map type.  The individual defaults
are described below.

\Subsection{File maps}
When \amd\ searches a file for a map entry it does a simple scan of the file
and supports both comments and continuation lines.

Continuation lines are indicated by a backslash character (``{\verb+\+}'') as
the last character of a line in the file.  The backslash, newline character
{\em and any leading white space on the following line} are discarded.  A maximum
line length of 2047 characters is enforced after continuation lines are read
but before comments are stripped.  Each line must end with
a newline character; that is newlines are terminators, not separators.
The following examples illustrate this:
\begin{verbatim}
key     valA   valB;   \
          valC
\end{verbatim}
specifies {\em three} locations, and is identical to
\begin{verbatim}
key     valA   valB;   valC
\end{verbatim}
However,
\begin{verbatim}
key     valA   valB;\
          valC
\end{verbatim}
specifies only {\em two} locations, and is identical to
\begin{verbatim}
key     valA   valB;valC
\end{verbatim}

After a complete line has been read from the file, including continuations,
\amd\ determines whether there is a comment on the line.
A comment begins with a hash (``{\tt \#}'') character and continues to the
end of the line.
There is no way to escape or change the comment lead-in character.

Note that continuation lines and comment support {\em only} apply to
file maps and ndbm maps built with the {\tt mk-amd-map} program.

When caching is enabled, file maps have a default cache mode of {\tt all} (\see \Ref{afs:cache}).

\Subsection{ndbm maps}\label{ndbm-maps}
An ndbm map may be used as a fast access form of a file map.
A program, {\tt mk-amd-map}, converts a normal map file into
an ndbm database.  This program supports the same continuation and
comment conventions that are provided for file maps.
Note that ndbm format files {\em may not} be
sharable across machine architectures.
The notion of speed generally only applies to large maps;
a small map, less than a single disk block, is almost certainly
better implemented as a file map.

ndbm maps do not support cache mode {\tt all} and, when
caching is enabled, have a default cache mode of {\tt inc} (\see \Ref{afs:cache}).

\Subsection{NIS maps}
When using NIS (formerly YP), an \amd\ map is implemented directly by the
underlying NIS map.
Comments and continuation lines are {\em not} supported
in the automounter and must be stripped when constructing the NIS server's database.

NIS maps do not support cache mode {\tt all} and,
when caching is enabled,
have a default cache mode of {\tt inc} (\see \Ref{afs:cache}).

\Subsection{Hesiod}
When the map name begins with the string ``{\tt hesiod.}'' lookups
are made using the {\em Hesiod} name server.  The string following
the dot is used as a name qualifier and is prepended with
the key being located.  The entire string is then resolved in the
{\t automount} context.  For example, if the map name is {\tt hesiod.homes}
and the key is {\tt jsp} then {\em Hesiod} is asked to resolve
{\tt jsp.homes.automount}.

Hesiod maps do not support cache mode {\tt all} and, when
caching is enabled, have a default cache mode of {\tt inc} (\see \Ref{afs:cache}).

\Subsection{Password}\label{map:passwd}
The password map support is unlike the four previous map types.
When the map name is the string {\tt /etc/passwd} 
\amd\ can lookup a user name in the password file and re-arrange
the home directory field to produce a usable map entry.

\Amd\ assumes the home directory has the format
{\tt /}{\em anydir}{\tt /}{\em dom$_1$}{\tt /../}{\em dom$_n$}{\tt /}{\em login}.
It breaks this string into a map entry where
\Var{rfs} has the value ``{\tt /}{\em anydir}{\tt /}{\em dom$_n$}'',
\Var{rhost} has the value ``{\em dom$_n$}{\tt .}{\em ...}{\tt .}{\em dom$_1$}'',
and \Var{sublink} has the value ``{\em login}''.

Thus if the password file entry was
\begin{quote}
\tt /home/achilles/jsp
\end{quote}
the map
entry used by \amd\ would be
\begin{quote}
\tt rfs:=/home/achilles;rhost:=achilles;sublink:=jsp
\end{quote}
Similarly, if the password file entry was
\begin{quote}
\tt /home/cc/sugar/mjh
\end{quote}
the map entry used by \amd\ would be 
\begin{quote}
\tt rfs:=/home/sugar;rhost:=sugar.cc;sublink:=jsp
\end{quote}

%\Subsection{Gdbm}

\Section{Key Lookup}

The key is located in the map whose type was determined when the
automount point was first created.
In general the key is a pathname component.
In some circumstances this may be modified by variable expansion
(\see \Ref{var-expansion})
and prefixing.
If the automount point has a prefix, specified by the \opt{pref} option, then
that is prepended to the search key before the map is searched.

If the key cannot be found then a {\em wildcard} match is attempted.
Currently this simply attempts to locate a special key ``{\tt *}''.
If the wildcard is not found then an error code is propagated back to the
kernel, otherwise \amd\ proceeds as if an exact match had been found.
The value field is then used to resolve the mount request (\see \Ref{filesystems}).


\Section{Location Format}\label{opts:values}

The value field from the lookup provides the information required to mount a filesystem.
The information is parsed according to the syntax shown in figure \ref{figure:so-grammar}.
\begin{figure}[htb]
\begin{tabbing}
Indent \= Long Gram Rule \= \kill
       \> {\em location-list}:\\
       \>              \> {\em location-selection}\\
       \>              \> {\em location-list}\ \verb*+ +\ {\tt ||}\ \verb*+ +\ {\em location-selection}\\
       \> {\em location-selection}:\\
       \>              \> {\em location}\\
       \>              \> {\em location-selection}\ \verb*+ +\ {\em location}\\
       \> {\em location}:\\
       \>              \> {\em location-info}\\
       \>              \> {\tt -}{\em location-info}\\
       \>              \> {\tt -}\\
       \> {\em location-info}:\\
       \>              \> {\em sel-or-opt}\\
       \>              \> {\em location-info}{\tt ;}{\em sel-or-opt}\\
       \>              \> {\tt ;}\\
       \> {\em sel-or-opt}:\\
       \>              \> {\em selection}\\
       \>              \> {\em opt-ass}\\
       \> {\em selection}:\\
       \>              \> {\rm selector}{\tt ==}{\em value}\\
       \>              \> {\rm selector}{\tt !=}{\em value}\\
       \> {\em opt-ass}:\\
       \>              \> {\rm option}{\tt :=}{\em value}\\
\end{tabbing}
\caption{\label{figure:so-grammar}Location syntax}
\end{figure}
Note that unquoted whitespace is not allowed in a location description.
White space is only allowed, and is mandatory, where shown with the symbol \verb*+ +.

A {\em location-selection} is a list of possible volumes with which to
satisfy the request.  {\em location-selection}s are separated by the {\tt ||}
operator.  The effect of this operator is to prevent use of location-selections
to its right if any of the location-selections on its left were selected
(see \Ref{selectors}).

The location-selection, and singleton {\em location-list},
{\tt type:=ufs;dev:=/dev/xd1g} would inform \amd\ to mount a
\UFS\ filesystem from the block special device {\tt /dev/xd1g}.

The {\em sel-or-opt} component is either the name of an option required by a
specific filesystem, or it is the name of a built-in, predefined selector such
as the architecture type.
The value may be quoted with double quotes ``{\tt "}'',
for example {\tt type:="ufs";dev:="/dev/xd1g"}.  These quotes are
stripped when the value is parsed and there is no way to get a double quote
into a value field.  Double quotes are used to get white space into a value field,
which is needed for the program filesystem (\see \Ref{pfs}).

\label{defaults}A location beginning with a dash ``{\tt -}'' is used
to specify default values for subsequent locations.
Any previously specified defaults in the location-list are discarded.  The
default string can be empty in which case no defaults apply.
The location {\tt -fs:=/mnt;opts:=ro} would set the local mount point
to {\tt /mnt} and cause mounts to be read-only by default.
Defaults specified this way are appended to, and so
override, any global map defaults given
with {\tt /defaults}\label{/defaults}).
A {\tt /defaults} value {\em gdef} and a location list
\begin{quote}
${\tt -}{\em def}_a\ $\verb*+ +$\ {\em loc}_{a_1}\ $\verb*+ +$\ {\em loc}_{a_2}\ $\verb*+ +$\ {\tt -}{\em def}_b\ $\verb*+ +$\ {\em loc}_{b_1}\ \ldots$
\end{quote}
is equivalent to
\begin{quote}
${\tt -}{\em gdef}{\tt ;}{\em def}_a\ $\verb*+ +$\ {\em loc}_{a_1}\ $\verb*+ +$\ {\em loc}_{a_2}\ $\verb*+ +$\ {\tt -}{\em gdef}{\tt ;}{\em def}_b\ $\verb*+ +$\ {\em loc}_{b_1}\ \ldots$
\end{quote}

\Subsection{Variable expansion}\label{var-expansion}

To allow generic location specifications \amd\ does variable expansion
on each location and also on some of the option strings.
Any option or selector appearing in the form \Var{{\em var}}
is replaced by the current value of that option or selector.
For example, if the value of \Var{key} was {\tt bin}, \Var{autodir} was {\tt /a}
and \Var{fs} was \Var{autodir}{\tt /local/}\Var{key} then after
expansion \Var{fs} would have the value {\tt /a/local/bin}.
Any environment variable can be accessed in a similar way.

Two pathname operators are available when expanding a variable.
If the variable name begins with ``{\tt /}'' then only the
last component of then pathname is substituted.  For example,
if \Var{path} was {\tt /foo/bar} then \Var{/path} would be
expanded to {\tt bar}.
Similarly, if the variable name ends with ``{\tt /}'' then all but
the last component of the pathname is substituted.
In the previous example, \Var{path/} would be expanded to {\tt /foo}.

Variable expansion is a two phase process.  Before a location is parsed, all
references to selectors, \eg\ \Var{path}, are expanded.  The location is then
parsed, selections are evaluated and option assignments recorded.  If there
were no selections or they all succeeded the location is used and the values of
the following options are expanded in the order given:
\opt{sublink}, \opt{rfs}, \opt{fs}, \opt{opts}, \opt{mount} and \opt{unmount}.
Note that expansion of option values is done after {\em all} assignments have
been completed and not in a purely left to right order as is done by the shell.
This generally has the desired effect but care must be taken if one of the
options references another, in which case the ordering can become significant.

There are two special cases concerning variable expansion.  Firstly, before a map
is consulted, any selectors in the name received from the kernel are expanded.
For example, if the request from the kernel was for \Var{arch}{\tt .bin} and the
machine architecture was {\tt vax}, the value given to \Var{key} would be {\tt vax.bin}.
Secondly, the value of \Var{rhost} is expanded and normalized before the other options
are expanded.  The normalization process strips any local sub-domain components.
For example, if \Var{domain} was {\tt Berkeley.EDU} and \Var{rhost} was initially
{\tt snow.Berkeley.EDU}, after the normalization it would simply be {\tt snow}.

\Subsection{Selectors}\label{selectors}

Selectors are used to control the use of a location.
It is possible to share a mount map between many machines in
such a way that filesystem location, architecture and operating
system differences are hidden from the users.
A selector of the form {\tt arch==sun3;os==sos4} would only apply
on Sun-3s running SunOS 4.$x$.

Selectors are evaluated left to right.  If a selector fails then that
location is ignored.  Thus the selectors form a conjunction and the
locations form a disjunction.
If all the locations are ignored or otherwise fail then \amd\ uses
the {\em error} filesystem (\see \Ref{error-fs}).  This is equivalent
to having a location {\tt type:=error} at the end of each mount-map
entry.

The selectors currently implemented are:

\begin{list}{}%
{\settowidth{\labelwidth}{{\tt autodir}}\setlength{\leftmargin}{1.2\labelwidth}}
\item[\tt arch\hfill]
the machine architecture which was automatically determined at compile time.
The architecture type can be displayed by running the command {\tt amd~-v}.
The currently supported architectures are listed in table \ref{table:arch}.
\begin{table}[htb]
\centering
\begin{tabular}{ll}
Name		& Architecture \\ \hline
\tt alliant	& Alliant FX/4 \\
\tt arm		& Acorn ARM \\
\tt encore      & Encore (reserved) \\
\tt fps500	& FPS Model 500 \\
\tt hp9000	& HP 9000/300 family \\
\tt hp9k8       & HP 9000/800 family (reserved) \\
\tt ibm032	& IBM RT \\
\tt ibm6000	& IBM RISC System/6000 \\
\tt macII	& Apple Mac II \\
\tt mips	& MIPS R2000 \\
\tt multimax	& Encore Multimax \\
\tt orion105	& HLH Orion 1/05 \\
\tt powernode	& Gould Powernode family \\
\tt sun3	& Sun-3 family \\
\tt sun4	& Sun-4 family \\
\tt tahoe	& Tahoe family \\
\tt vax		& DEC \sc Vax \\
\end{tabular}
\caption{\label{table:arch}Architectures supported by \amd}
\end{table}

\item[\tt autodir\hfill]
the default directory under which to mount filesystems.
This may be changed by the ``-a'' command line option.
See the \opt{fs} option.

\item[\tt byte\hfill]\label{byte-selector}
the machine's byte ordering.  This is either {\tt little}, indicating
little-endian, or {\tt big}, indicating big-endian.
One possible use is to share {\tt rwho} databases (see \Ref{example:rwho}).
Another is to share ndbm databases,
however this use can be considered a courageous juggling act.

\item[\tt cluster\hfill]
is provided as a hook for the name of the local cluster.  This can
be used to decide which servers to use for copies of replicated filesystems.
\Var{cluster} defaults to the value of \Var{domain} unless a different
value is set with the ``-C'' command line option.

\item[\tt domain\hfill]
the local domain name as specified by the ``-d'' command line option.
See {\tt host}.

\item[\tt host\hfill]
the local hostname as determined by {\bf gethostname}(2).
If no domain name was specified on the command line
and the hostname contains a period ``{\tt .}'' then the string
before the period is used as the host name, and the string
after the period is assigned to \Var{domain}.
For example, if the hostname is {\tt styx.doc.ic.ac.uk} the {\tt host}
would be {\tt styx} and {\tt domain} would be {\tt doc.ic.ac.uk}.
{\tt hostd} would be {\tt styx.doc.ic.ac.uk}.

\item[\tt hostd\hfill]
is \Var{host} and \Var{domain} concatenated with a ``{\tt .}'' inserted between them
if required.
If \Var{domain} is an empty string then \Var{host} and \Var{hostd} will
be identical.

\item[\tt karch\hfill]
is provided as a hook for the kernel architecture.  This is used
on SunOS 4, for example, to distinguish between different {\tt /usr/kvm} volumes.
\Var{karch} defaults to the value of \Var{arch} unless a different
value is set with the ``-k'' command line option.

\item[\tt os\hfill]
the operating system.
Like the machine architecture, this is automatically determined at compile time.
The operating system name can be displayed by running the command {\tt amd~-v}.
The currently supported operating systems are listed in table \ref{table:os}.
\begin{table}[htb]
\centering
\begin{tabular}{ll}
Name		& System \\ \hline
\tt acis43	& 4.3 BSD for IBM RT \\
\tt aix3	& AIX 3.1 \\
\tt aux		& System V for Mac-II \\
\tt bsd44	& 4.4 BSD \\
\tt concentrix	& Concentrix 5.0 \\
\tt fpx4	& Celerity FPX 4.1/2 \\
\tt hlh42	& HLH OTS 1.$x$ (4.2 BSD) \\
\tt hpux	& HP-UX 6.$x$ \\
\tt riscix	& Acorn RISC iX \\
\tt sos3	& SunOS 3.4 \& 3.5 \\
\tt sos4	& SunOS 4.$x$ \\
\tt umax43	& Umax 4.3 BSD \\
\tt u2\_2	& Ultrix 2.2 \\
\tt u3\_0	& Ultrix 3.0 \\
\tt utx32	& Gould UTX/32 Rel 2.$x$ \\
\tt xinu43	& mt Xinu MORE/bsd \\
\end{tabular}
\caption{\label{table:os}Operating systems supported by \amd}
\end{table}
\end{list}

The following selectors are also provided.  Unlike the other selectors,
they vary for each lookup.
Note that when the name from the kernel is expanded prior to a map
lookup, these selectors are all defined as empty strings.
\begin{list}{}%
{\settowidth{\labelwidth}{{\tt autodir}}\setlength{\leftmargin}{1.2\labelwidth}}
\item[\tt key\hfill]
the name being resolved.
For example, if {\tt /home} is an automount point, then accessing
{\tt /home/foo}\label{foo-path} would set \Var{key} to the string {\tt foo}.
The key is prefixed by the \opt{pref} option set in the parent mount point.
The default prefix is an empty string.  If the prefix was {\tt blah/} then
\Var{key} would be set to {\tt blah/foo}.

\item[\tt map\hfill]
the name of the mount map being used.

\item[\tt path\hfill]
the full pathname of the name being resolved.  For example {\tt /home/foo}
in the example above.

\end{list}

Selectors can be negated by using {\tt !=} instead of {\tt ==}.
For example to select a location
on all non-{\sc Vax} machines the selector {\tt arch!=vax} would be used. 

\Subsection{Options}\label{options}

Options are parsed concurrently with selectors.  The difference is that
when an option is seen the string following the ``{\tt :=}'' is recorded for
later use.  As a minimum the \opt{type} option must be specified.
Each filesystem type has other options which must also be specified.
The filesystem specific options are detailed in \Ref{filesystems}.

The following options apply to more than one filesystem type:
\begin{list}{}
{\settowidth{\labelwidth}{{\tt sublink}}\setlength{\leftmargin}{1.2\labelwidth}}
\item[\tt delay\hfill]
the delay, in seconds, before an attempt will be made to mount from the current location.
Auxilliary data, such as network address, file handles and so on are computed
regardless of this value.
A delay can be used to implement the notion of primary and secondary file servers.
The secondary servers would have a delay of a few seconds,
thus giving the primary servers a chance to respond first.

\item[\tt fs\hfill]\label{mount location}
the local mount point.
The semantics of this option vary between filesystems.

For \NFS\ and \UFS\ filesystems the value of \Var{fs} is used as the local
mount point.  It is important that this string uniquely identifies the
filesystem being mounted.  To satisfy this requirement, it should contain the
name of the host on which the filesystem is resident and the pathname
of the filesystem on the local or remote host.

The reason for
requiring the hostname is clear if replicated filesystems are considered.
If a fileserver goes down and a replacement filesystem is mounted then the {\em local}
mount point {\em must} be different from that of the filesystem which
is hung.
Some encoding of the filesystem name is required if more than one filesystem
is to be mounted from any given host.

If the hostname is first in the path then all mounts from a particular
host will be gathered below a single directory.  If that server goes
down then the hung mount points are less likely to be accidentally referenced,
for example when {\bf getwd}(3) traverses the namespace to find the pathname
of the current directory.

The {\tt fs} defaults to \Var{autodir}/\Var{rhost}\Var{rfs}.
In addition, {\tt rhost} defaults to the local host name (\Var{host}) and
{\tt rfs} defaults to the value of \Var{path}, which
is the full path of the requested file; {\tt /home/foo}
in the example above (\see \Ref{foo-path}).
\Var{autodir} defaults to {\tt /a} but may be changed with the ``-a''
command line option\footnote{Sun's automounter defaults to {\tt /tmp\_mnt}}.
Note that there is no ``{\tt /}'' between the \Var{rhost} and \Var{rfs} since
\Var{rfs} begins with a ``{\tt /}''.

\item[\tt opts\hfill]
the options to pass to the mount system call.
A leading ``{\tt -}'' is silently ignored.
The mount options supported generally correspond to
those used by {\bf mount}(8) and are listed in table \ref{table:mount opts}.
Some additional pseudo-options are interpreted by \amd\ and
are listed in table \ref{table:pseudo-mount opts}.
Unless specifically overridden, each of the system default mount
options applies.
Any options not recognised are ignored.
If no options list is supplied the string {\tt rw,defaults} is used
and all the system default mount options apply.
\begin{table}[htb]
\centering
\begin{tabular}{lp{4in}}
Option		& Semantics \\\hline
\tt grpid	& Use BSD directory group-id semantics. \\
\tt intr	& Allow keyboard interrupts on hard mounts. \\
\tt nodevs	& Don't allow local special devices on this filesystem. \\
\tt nosuid	& Don't allow set-uid or set-gid executables on this filesystem. \\
\tt quota	& Enable quota checking on this mount. \\
\tt retrans=$n$	& The number of \NFS\ retransmits made before a user error is generated
		  by a {\tt soft} mounted filesystem, and before a
		  {\tt hard} mounted filesystem reports {\tt NFS server {\em yoyo}
		  not responding still trying}. \\
\tt ro		& Mount this filesystem readonly. \\
\tt soft	& Give up after {\em retrans} retransmissions. \\
\tt tcp		& Use TCP/IP instead of UDP/IP \\
\tt timeo=$n$	& The \NFS\ timeout, in tenth-seconds, before a request is retransmitted. \\
\end{tabular}
\caption{Mount options passed to the mount system call\label{table:mount opts}}
\end{table}

\begin{table}[htb]
\centering
\begin{tabular}{lp{4in}}
Option		& Semantics \\\hline
\tt notimeout	& Configures the mount so that its time-to-live will
		  never expire.  This is also the default for some
		  filesystem types. \\
%
% Implementation broken:
\tt ping=$n$	& The interval, in seconds, between keep-alive pings.  When four
		  consecutive pings have failed the mount point is
		  marked as hung.  This interval defaults to 30 seconds.
		  If the ping interval is negative, no pings are sent and
		  the host is assumed to be always up.  Pings are never sent
		  for a TCP mount.  \\

\tt retry=$n$	& The number of times to retry the mount system call. \\
\tt utimeout=$n$& The interval, in seconds, by which the mount's
		  time-to-live\label{opt:utimeout}
		  is extended after an unmount attempt has failed.
		  In fact the interval is extended before the unmount
		  is attempted to avoid thrashing.  The default value
                  is 120 seconds (two minutes) or as set by the ``-w''
                  command line option. \\
\end{tabular}
\caption{Mount options interpreted by \amd\label{table:pseudo-mount opts}}
\end{table}

\item[\tt sublink\hfill]
the subdirectory within the mounted filesystem to which the reference
should point.
This can be used to prevent duplicate mounts in cases where multiple
directories in the same mounted filesystem are used.

\item[\tt type\hfill]
the filesystem type to be used.  A full description of each
type is given in \Ref{filesystems}.

\end{list}

Superfluous option specifications are ignored and are not reported
as errors.

This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.