![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to maps.tex CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [CSRG BSD Unix] / 43BSDReno / usr.sbin / amd / doc|
Return to maps.tex CVS log | Up to [CSRG BSD Unix] / 43BSDReno / usr.sbin / amd / doc |
1.1 root 1: % $Id: maps.tex,v 5.2 90/06/23 22:21:51 jsp Rel $
2: %
3: % Copyright (c) 1989 Jan-Simon Pendry
4: % Copyright (c) 1989 Imperial College of Science, Technology & Medicine
5: % Copyright (c) 1989 The Regents of the University of California.
6: % All rights reserved.
7: %
8: % This code is derived from software contributed to Berkeley by
9: % Jan-Simon Pendry at Imperial College, London.
10: %
11: % Redistribution and use in source and binary forms are permitted provided
12: % that: (1) source distributions retain this entire copyright notice and
13: % comment, and (2) distributions including binaries display the following
14: % acknowledgement: ``This product includes software developed by the
15: % University of California, Berkeley and its contributors'' in the
16: % documentation or other materials provided with the distribution and in
17: % all advertising materials mentioning features or use of this software.
18: % Neither the name of the University nor the names of its contributors may
19: % be used to endorse or promote products derived from this software without
20: % specific prior written permission.
21: % THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR IMPLIED
22: % WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF
23: % MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
24: %
25: % @(#)maps.tex 5.1 (Berkeley) 7/19/90
26:
27:
28: \Chapter{Mount-maps}
29:
30: \Amd\ has no built-in knowledge of machines or filesystems.
31: External {\em mount-maps} are used to provide the required information.
32: Specifically, \amd\ needs to know when and under what conditions it should
33: mount filesystems.
34:
35: The map entry corresponding to the requested name contains
36: a list of possible locations from which to resolve the request.
37: Each location specifies filesystem type, information required by that
38: filesystem (for example the block special device in the case of \UFS), and
39: some information describing where to mount the filesystem (\see \Ref{mount location}).
40: A location may also contain {\em selectors} (\see \Ref{selectors}).
41:
42: \Section{Map Types}
43:
44: A mount-map can be implemented as a regular file, an ndbm database
45: a YP map \cite{sun:yp} or via
46: the {\em Hesiod} \cite{mit:hesiod} name
47: server.
48: In addition, the password ``file'' can be used as a source of
49: map information.
50: %\footnote{In future, gdbm databases will also be supported.}
51: A mount-map name is a sequence of characters.
52: When an automount point is created a handle on the mount-map
53: is obtained. If the the map name begins with the sequence
54: ``{\tt hesiod.}''\ then the {\em Hesiod} name server will be used.
55: If the map name is the string ``{\tt /etc/passwd}'' then the password
56: ``file'' will be used.
57: Otherwise the map name is referenced as a file,
58: then as an ndbm database by that name and then as a YP map.
59: As soon as a valid reference is found the map type is noted
60: for future use but any resources held are released, for example
61: any open file descriptors are closed.
62: The available map types are a configurable component of \amd\ and
63: can be displayed by running the command {\tt amd~-v}.
64:
65: By default, \amd\ does not cache any data retrieved from a mount map.
66: This is a policy decision based on the observation that most workstations
67: have more available CPU time than spare memory.
68: However, on a multi-user service or larger workstation the faster
69: response provided by a cache can be preferable. The \opt{cache}
70: option can be specified on automount points to alter the
71: caching behaviour (\see \Ref{auto-fs}).
72: Specifying {\tt cache:=mapdefault} selects a suitable default
73: cache mode depending on the map type. The individual defaults
74: are described below.
75:
76: \Subsection{File maps}
77: When \amd\ searches a file for a map entry it does a simple scan of the file
78: and supports both comments and continuation lines.
79:
80: Continuation lines are indicated by a backslash character (``{\verb+\+}'') as
81: the last character of a line in the file. The backslash, newline character
82: {\em and any leading white space on the following line} are discarded. A maximum
83: line length of 2047 characters is enforced after continuation lines are read
84: but before comments are stripped. Each line must end with
85: a newline character; that is newlines are terminators, not separators.
86: The following examples illustrate this:
87: \begin{verbatim}
88: key valA valB; \
89: valC
90: \end{verbatim}
91: specifies {\em three} locations, and is identical to
92: \begin{verbatim}
93: key valA valB; valC
94: \end{verbatim}
95: However,
96: \begin{verbatim}
97: key valA valB;\
98: valC
99: \end{verbatim}
100: specifies only {\em two} locations, and is identical to
101: \begin{verbatim}
102: key valA valB;valC
103: \end{verbatim}
104:
105: After a complete line has been read from the file, including continuations,
106: \amd\ determines whether there is a comment on the line.
107: A comment begins with a hash (``{\tt \#}'') character and continues to the
108: end of the line.
109: There is no way to escape or change the comment lead-in character.
110:
111: Note that continuation lines and comment support {\em only} apply to
112: file maps and ndbm maps built with the {\tt mk-amd-map} program.
113:
114: When caching is enabled, file maps have a default cache mode of {\tt all} (\see \Ref{afs:cache}).
115:
116: \Subsection{ndbm maps}\label{ndbm-maps}
117: An ndbm map may be used as a fast access form of a file map.
118: A program, {\tt mk-amd-map}, converts a normal map file into
119: an ndbm database. This program supports the same continuation and
120: comment conventions that are provided for file maps.
121: Note that ndbm format files {\em may not} be
122: sharable across machine architectures.
123: The notion of speed generally only applies to large maps;
124: a small map, less than a single disk block, is almost certainly
125: better implemented as a file map.
126:
127: ndbm maps do not support cache mode {\tt all} and, when
128: caching is enabled, have a default cache mode of {\tt inc} (\see \Ref{afs:cache}).
129:
130: \Subsection{NIS maps}
131: When using NIS (formerly YP), an \amd\ map is implemented directly by the
132: underlying NIS map.
133: Comments and continuation lines are {\em not} supported
134: in the automounter and must be stripped when constructing the NIS server's database.
135:
136: NIS maps do not support cache mode {\tt all} and,
137: when caching is enabled,
138: have a default cache mode of {\tt inc} (\see \Ref{afs:cache}).
139:
140: \Subsection{Hesiod}
141: When the map name begins with the string ``{\tt hesiod.}'' lookups
142: are made using the {\em Hesiod} name server. The string following
143: the dot is used as a name qualifier and is prepended with
144: the key being located. The entire string is then resolved in the
145: {\t automount} context. For example, if the map name is {\tt hesiod.homes}
146: and the key is {\tt jsp} then {\em Hesiod} is asked to resolve
147: {\tt jsp.homes.automount}.
148:
149: Hesiod maps do not support cache mode {\tt all} and, when
150: caching is enabled, have a default cache mode of {\tt inc} (\see \Ref{afs:cache}).
151:
152: \Subsection{Password}\label{map:passwd}
153: The password map support is unlike the four previous map types.
154: When the map name is the string {\tt /etc/passwd}
155: \amd\ can lookup a user name in the password file and re-arrange
156: the home directory field to produce a usable map entry.
157:
158: \Amd\ assumes the home directory has the format
159: {\tt /}{\em anydir}{\tt /}{\em dom$_1$}{\tt /../}{\em dom$_n$}{\tt /}{\em login}.
160: It breaks this string into a map entry where
161: \Var{rfs} has the value ``{\tt /}{\em anydir}{\tt /}{\em dom$_n$}'',
162: \Var{rhost} has the value ``{\em dom$_n$}{\tt .}{\em ...}{\tt .}{\em dom$_1$}'',
163: and \Var{sublink} has the value ``{\em login}''.
164:
165: Thus if the password file entry was
166: \begin{quote}
167: \tt /home/achilles/jsp
168: \end{quote}
169: the map
170: entry used by \amd\ would be
171: \begin{quote}
172: \tt rfs:=/home/achilles;rhost:=achilles;sublink:=jsp
173: \end{quote}
174: Similarly, if the password file entry was
175: \begin{quote}
176: \tt /home/cc/sugar/mjh
177: \end{quote}
178: the map entry used by \amd\ would be
179: \begin{quote}
180: \tt rfs:=/home/sugar;rhost:=sugar.cc;sublink:=jsp
181: \end{quote}
182:
183: %\Subsection{Gdbm}
184:
185: \Section{Key Lookup}
186:
187: The key is located in the map whose type was determined when the
188: automount point was first created.
189: In general the key is a pathname component.
190: In some circumstances this may be modified by variable expansion
191: (\see \Ref{var-expansion})
192: and prefixing.
193: If the automount point has a prefix, specified by the \opt{pref} option, then
194: that is prepended to the search key before the map is searched.
195:
196: If the key cannot be found then a {\em wildcard} match is attempted.
197: Currently this simply attempts to locate a special key ``{\tt *}''.
198: If the wildcard is not found then an error code is propagated back to the
199: kernel, otherwise \amd\ proceeds as if an exact match had been found.
200: The value field is then used to resolve the mount request (\see \Ref{filesystems}).
201:
202:
203: \Section{Location Format}\label{opts:values}
204:
205: The value field from the lookup provides the information required to mount a filesystem.
206: The information is parsed according to the syntax shown in figure \ref{figure:so-grammar}.
207: \begin{figure}[htb]
208: \begin{tabbing}
209: Indent \= Long Gram Rule \= \kill
210: \> {\em location-list}:\\
211: \> \> {\em location-selection}\\
212: \> \> {\em location-list}\ \verb*+ +\ {\tt ||}\ \verb*+ +\ {\em location-selection}\\
213: \> {\em location-selection}:\\
214: \> \> {\em location}\\
215: \> \> {\em location-selection}\ \verb*+ +\ {\em location}\\
216: \> {\em location}:\\
217: \> \> {\em location-info}\\
218: \> \> {\tt -}{\em location-info}\\
219: \> \> {\tt -}\\
220: \> {\em location-info}:\\
221: \> \> {\em sel-or-opt}\\
222: \> \> {\em location-info}{\tt ;}{\em sel-or-opt}\\
223: \> \> {\tt ;}\\
224: \> {\em sel-or-opt}:\\
225: \> \> {\em selection}\\
226: \> \> {\em opt-ass}\\
227: \> {\em selection}:\\
228: \> \> {\rm selector}{\tt ==}{\em value}\\
229: \> \> {\rm selector}{\tt !=}{\em value}\\
230: \> {\em opt-ass}:\\
231: \> \> {\rm option}{\tt :=}{\em value}\\
232: \end{tabbing}
233: \caption{\label{figure:so-grammar}Location syntax}
234: \end{figure}
235: Note that unquoted whitespace is not allowed in a location description.
236: White space is only allowed, and is mandatory, where shown with the symbol \verb*+ +.
237:
238: A {\em location-selection} is a list of possible volumes with which to
239: satisfy the request. {\em location-selection}s are separated by the {\tt ||}
240: operator. The effect of this operator is to prevent use of location-selections
241: to its right if any of the location-selections on its left were selected
242: (see \Ref{selectors}).
243:
244: The location-selection, and singleton {\em location-list},
245: {\tt type:=ufs;dev:=/dev/xd1g} would inform \amd\ to mount a
246: \UFS\ filesystem from the block special device {\tt /dev/xd1g}.
247:
248: The {\em sel-or-opt} component is either the name of an option required by a
249: specific filesystem, or it is the name of a built-in, predefined selector such
250: as the architecture type.
251: The value may be quoted with double quotes ``{\tt "}'',
252: for example {\tt type:="ufs";dev:="/dev/xd1g"}. These quotes are
253: stripped when the value is parsed and there is no way to get a double quote
254: into a value field. Double quotes are used to get white space into a value field,
255: which is needed for the program filesystem (\see \Ref{pfs}).
256:
257: \label{defaults}A location beginning with a dash ``{\tt -}'' is used
258: to specify default values for subsequent locations.
259: Any previously specified defaults in the location-list are discarded. The
260: default string can be empty in which case no defaults apply.
261: The location {\tt -fs:=/mnt;opts:=ro} would set the local mount point
262: to {\tt /mnt} and cause mounts to be read-only by default.
263: Defaults specified this way are appended to, and so
264: override, any global map defaults given
265: with {\tt /defaults}\label{/defaults}).
266: A {\tt /defaults} value {\em gdef} and a location list
267: \begin{quote}
268: ${\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$
269: \end{quote}
270: is equivalent to
271: \begin{quote}
272: ${\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$
273: \end{quote}
274:
275: \Subsection{Variable expansion}\label{var-expansion}
276:
277: To allow generic location specifications \amd\ does variable expansion
278: on each location and also on some of the option strings.
279: Any option or selector appearing in the form \Var{{\em var}}
280: is replaced by the current value of that option or selector.
281: For example, if the value of \Var{key} was {\tt bin}, \Var{autodir} was {\tt /a}
282: and \Var{fs} was \Var{autodir}{\tt /local/}\Var{key} then after
283: expansion \Var{fs} would have the value {\tt /a/local/bin}.
284: Any environment variable can be accessed in a similar way.
285:
286: Two pathname operators are available when expanding a variable.
287: If the variable name begins with ``{\tt /}'' then only the
288: last component of then pathname is substituted. For example,
289: if \Var{path} was {\tt /foo/bar} then \Var{/path} would be
290: expanded to {\tt bar}.
291: Similarly, if the variable name ends with ``{\tt /}'' then all but
292: the last component of the pathname is substituted.
293: In the previous example, \Var{path/} would be expanded to {\tt /foo}.
294:
295: Variable expansion is a two phase process. Before a location is parsed, all
296: references to selectors, \eg\ \Var{path}, are expanded. The location is then
297: parsed, selections are evaluated and option assignments recorded. If there
298: were no selections or they all succeeded the location is used and the values of
299: the following options are expanded in the order given:
300: \opt{sublink}, \opt{rfs}, \opt{fs}, \opt{opts}, \opt{mount} and \opt{unmount}.
301: Note that expansion of option values is done after {\em all} assignments have
302: been completed and not in a purely left to right order as is done by the shell.
303: This generally has the desired effect but care must be taken if one of the
304: options references another, in which case the ordering can become significant.
305:
306: There are two special cases concerning variable expansion. Firstly, before a map
307: is consulted, any selectors in the name received from the kernel are expanded.
308: For example, if the request from the kernel was for \Var{arch}{\tt .bin} and the
309: machine architecture was {\tt vax}, the value given to \Var{key} would be {\tt vax.bin}.
310: Secondly, the value of \Var{rhost} is expanded and normalized before the other options
311: are expanded. The normalization process strips any local sub-domain components.
312: For example, if \Var{domain} was {\tt Berkeley.EDU} and \Var{rhost} was initially
313: {\tt snow.Berkeley.EDU}, after the normalization it would simply be {\tt snow}.
314:
315: \Subsection{Selectors}\label{selectors}
316:
317: Selectors are used to control the use of a location.
318: It is possible to share a mount map between many machines in
319: such a way that filesystem location, architecture and operating
320: system differences are hidden from the users.
321: A selector of the form {\tt arch==sun3;os==sos4} would only apply
322: on Sun-3s running SunOS 4.$x$.
323:
324: Selectors are evaluated left to right. If a selector fails then that
325: location is ignored. Thus the selectors form a conjunction and the
326: locations form a disjunction.
327: If all the locations are ignored or otherwise fail then \amd\ uses
328: the {\em error} filesystem (\see \Ref{error-fs}). This is equivalent
329: to having a location {\tt type:=error} at the end of each mount-map
330: entry.
331:
332: The selectors currently implemented are:
333:
334: \begin{list}{}%
335: {\settowidth{\labelwidth}{{\tt autodir}}\setlength{\leftmargin}{1.2\labelwidth}}
336: \item[\tt arch\hfill]
337: the machine architecture which was automatically determined at compile time.
338: The architecture type can be displayed by running the command {\tt amd~-v}.
339: The currently supported architectures are listed in table \ref{table:arch}.
340: \begin{table}[htb]
341: \centering
342: \begin{tabular}{ll}
343: Name & Architecture \\ \hline
344: \tt alliant & Alliant FX/4 \\
345: \tt arm & Acorn ARM \\
346: \tt encore & Encore (reserved) \\
347: \tt fps500 & FPS Model 500 \\
348: \tt hp9000 & HP 9000/300 family \\
349: \tt hp9k8 & HP 9000/800 family (reserved) \\
350: \tt ibm032 & IBM RT \\
351: \tt ibm6000 & IBM RISC System/6000 \\
352: \tt macII & Apple Mac II \\
353: \tt mips & MIPS R2000 \\
354: \tt multimax & Encore Multimax \\
355: \tt orion105 & HLH Orion 1/05 \\
356: \tt powernode & Gould Powernode family \\
357: \tt sun3 & Sun-3 family \\
358: \tt sun4 & Sun-4 family \\
359: \tt tahoe & Tahoe family \\
360: \tt vax & DEC \sc Vax \\
361: \end{tabular}
362: \caption{\label{table:arch}Architectures supported by \amd}
363: \end{table}
364:
365: \item[\tt autodir\hfill]
366: the default directory under which to mount filesystems.
367: This may be changed by the ``-a'' command line option.
368: See the \opt{fs} option.
369:
370: \item[\tt byte\hfill]\label{byte-selector}
371: the machine's byte ordering. This is either {\tt little}, indicating
372: little-endian, or {\tt big}, indicating big-endian.
373: One possible use is to share {\tt rwho} databases (see \Ref{example:rwho}).
374: Another is to share ndbm databases,
375: however this use can be considered a courageous juggling act.
376:
377: \item[\tt cluster\hfill]
378: is provided as a hook for the name of the local cluster. This can
379: be used to decide which servers to use for copies of replicated filesystems.
380: \Var{cluster} defaults to the value of \Var{domain} unless a different
381: value is set with the ``-C'' command line option.
382:
383: \item[\tt domain\hfill]
384: the local domain name as specified by the ``-d'' command line option.
385: See {\tt host}.
386:
387: \item[\tt host\hfill]
388: the local hostname as determined by {\bf gethostname}(2).
389: If no domain name was specified on the command line
390: and the hostname contains a period ``{\tt .}'' then the string
391: before the period is used as the host name, and the string
392: after the period is assigned to \Var{domain}.
393: For example, if the hostname is {\tt styx.doc.ic.ac.uk} the {\tt host}
394: would be {\tt styx} and {\tt domain} would be {\tt doc.ic.ac.uk}.
395: {\tt hostd} would be {\tt styx.doc.ic.ac.uk}.
396:
397: \item[\tt hostd\hfill]
398: is \Var{host} and \Var{domain} concatenated with a ``{\tt .}'' inserted between them
399: if required.
400: If \Var{domain} is an empty string then \Var{host} and \Var{hostd} will
401: be identical.
402:
403: \item[\tt karch\hfill]
404: is provided as a hook for the kernel architecture. This is used
405: on SunOS 4, for example, to distinguish between different {\tt /usr/kvm} volumes.
406: \Var{karch} defaults to the value of \Var{arch} unless a different
407: value is set with the ``-k'' command line option.
408:
409: \item[\tt os\hfill]
410: the operating system.
411: Like the machine architecture, this is automatically determined at compile time.
412: The operating system name can be displayed by running the command {\tt amd~-v}.
413: The currently supported operating systems are listed in table \ref{table:os}.
414: \begin{table}[htb]
415: \centering
416: \begin{tabular}{ll}
417: Name & System \\ \hline
418: \tt acis43 & 4.3 BSD for IBM RT \\
419: \tt aix3 & AIX 3.1 \\
420: \tt aux & System V for Mac-II \\
421: \tt bsd44 & 4.4 BSD \\
422: \tt concentrix & Concentrix 5.0 \\
423: \tt fpx4 & Celerity FPX 4.1/2 \\
424: \tt hlh42 & HLH OTS 1.$x$ (4.2 BSD) \\
425: \tt hpux & HP-UX 6.$x$ \\
426: \tt riscix & Acorn RISC iX \\
427: \tt sos3 & SunOS 3.4 \& 3.5 \\
428: \tt sos4 & SunOS 4.$x$ \\
429: \tt umax43 & Umax 4.3 BSD \\
430: \tt u2\_2 & Ultrix 2.2 \\
431: \tt u3\_0 & Ultrix 3.0 \\
432: \tt utx32 & Gould UTX/32 Rel 2.$x$ \\
433: \tt xinu43 & mt Xinu MORE/bsd \\
434: \end{tabular}
435: \caption{\label{table:os}Operating systems supported by \amd}
436: \end{table}
437: \end{list}
438:
439: The following selectors are also provided. Unlike the other selectors,
440: they vary for each lookup.
441: Note that when the name from the kernel is expanded prior to a map
442: lookup, these selectors are all defined as empty strings.
443: \begin{list}{}%
444: {\settowidth{\labelwidth}{{\tt autodir}}\setlength{\leftmargin}{1.2\labelwidth}}
445: \item[\tt key\hfill]
446: the name being resolved.
447: For example, if {\tt /home} is an automount point, then accessing
448: {\tt /home/foo}\label{foo-path} would set \Var{key} to the string {\tt foo}.
449: The key is prefixed by the \opt{pref} option set in the parent mount point.
450: The default prefix is an empty string. If the prefix was {\tt blah/} then
451: \Var{key} would be set to {\tt blah/foo}.
452:
453: \item[\tt map\hfill]
454: the name of the mount map being used.
455:
456: \item[\tt path\hfill]
457: the full pathname of the name being resolved. For example {\tt /home/foo}
458: in the example above.
459:
460: \end{list}
461:
462: Selectors can be negated by using {\tt !=} instead of {\tt ==}.
463: For example to select a location
464: on all non-{\sc Vax} machines the selector {\tt arch!=vax} would be used.
465:
466: \Subsection{Options}\label{options}
467:
468: Options are parsed concurrently with selectors. The difference is that
469: when an option is seen the string following the ``{\tt :=}'' is recorded for
470: later use. As a minimum the \opt{type} option must be specified.
471: Each filesystem type has other options which must also be specified.
472: The filesystem specific options are detailed in \Ref{filesystems}.
473:
474: The following options apply to more than one filesystem type:
475: \begin{list}{}
476: {\settowidth{\labelwidth}{{\tt sublink}}\setlength{\leftmargin}{1.2\labelwidth}}
477: \item[\tt delay\hfill]
478: the delay, in seconds, before an attempt will be made to mount from the current location.
479: Auxilliary data, such as network address, file handles and so on are computed
480: regardless of this value.
481: A delay can be used to implement the notion of primary and secondary file servers.
482: The secondary servers would have a delay of a few seconds,
483: thus giving the primary servers a chance to respond first.
484:
485: \item[\tt fs\hfill]\label{mount location}
486: the local mount point.
487: The semantics of this option vary between filesystems.
488:
489: For \NFS\ and \UFS\ filesystems the value of \Var{fs} is used as the local
490: mount point. It is important that this string uniquely identifies the
491: filesystem being mounted. To satisfy this requirement, it should contain the
492: name of the host on which the filesystem is resident and the pathname
493: of the filesystem on the local or remote host.
494:
495: The reason for
496: requiring the hostname is clear if replicated filesystems are considered.
497: If a fileserver goes down and a replacement filesystem is mounted then the {\em local}
498: mount point {\em must} be different from that of the filesystem which
499: is hung.
500: Some encoding of the filesystem name is required if more than one filesystem
501: is to be mounted from any given host.
502:
503: If the hostname is first in the path then all mounts from a particular
504: host will be gathered below a single directory. If that server goes
505: down then the hung mount points are less likely to be accidentally referenced,
506: for example when {\bf getwd}(3) traverses the namespace to find the pathname
507: of the current directory.
508:
509: The {\tt fs} defaults to \Var{autodir}/\Var{rhost}\Var{rfs}.
510: In addition, {\tt rhost} defaults to the local host name (\Var{host}) and
511: {\tt rfs} defaults to the value of \Var{path}, which
512: is the full path of the requested file; {\tt /home/foo}
513: in the example above (\see \Ref{foo-path}).
514: \Var{autodir} defaults to {\tt /a} but may be changed with the ``-a''
515: command line option\footnote{Sun's automounter defaults to {\tt /tmp\_mnt}}.
516: Note that there is no ``{\tt /}'' between the \Var{rhost} and \Var{rfs} since
517: \Var{rfs} begins with a ``{\tt /}''.
518:
519: \item[\tt opts\hfill]
520: the options to pass to the mount system call.
521: A leading ``{\tt -}'' is silently ignored.
522: The mount options supported generally correspond to
523: those used by {\bf mount}(8) and are listed in table \ref{table:mount opts}.
524: Some additional pseudo-options are interpreted by \amd\ and
525: are listed in table \ref{table:pseudo-mount opts}.
526: Unless specifically overridden, each of the system default mount
527: options applies.
528: Any options not recognised are ignored.
529: If no options list is supplied the string {\tt rw,defaults} is used
530: and all the system default mount options apply.
531: \begin{table}[htb]
532: \centering
533: \begin{tabular}{lp{4in}}
534: Option & Semantics \\\hline
535: \tt grpid & Use BSD directory group-id semantics. \\
536: \tt intr & Allow keyboard interrupts on hard mounts. \\
537: \tt nodevs & Don't allow local special devices on this filesystem. \\
538: \tt nosuid & Don't allow set-uid or set-gid executables on this filesystem. \\
539: \tt quota & Enable quota checking on this mount. \\
540: \tt retrans=$n$ & The number of \NFS\ retransmits made before a user error is generated
541: by a {\tt soft} mounted filesystem, and before a
542: {\tt hard} mounted filesystem reports {\tt NFS server {\em yoyo}
543: not responding still trying}. \\
544: \tt ro & Mount this filesystem readonly. \\
545: \tt soft & Give up after {\em retrans} retransmissions. \\
546: \tt tcp & Use TCP/IP instead of UDP/IP \\
547: \tt timeo=$n$ & The \NFS\ timeout, in tenth-seconds, before a request is retransmitted. \\
548: \end{tabular}
549: \caption{Mount options passed to the mount system call\label{table:mount opts}}
550: \end{table}
551:
552: \begin{table}[htb]
553: \centering
554: \begin{tabular}{lp{4in}}
555: Option & Semantics \\\hline
556: \tt notimeout & Configures the mount so that its time-to-live will
557: never expire. This is also the default for some
558: filesystem types. \\
559: %
560: % Implementation broken:
561: \tt ping=$n$ & The interval, in seconds, between keep-alive pings. When four
562: consecutive pings have failed the mount point is
563: marked as hung. This interval defaults to 30 seconds.
564: If the ping interval is negative, no pings are sent and
565: the host is assumed to be always up. Pings are never sent
566: for a TCP mount. \\
567:
568: \tt retry=$n$ & The number of times to retry the mount system call. \\
569: \tt utimeout=$n$& The interval, in seconds, by which the mount's
570: time-to-live\label{opt:utimeout}
571: is extended after an unmount attempt has failed.
572: In fact the interval is extended before the unmount
573: is attempted to avoid thrashing. The default value
574: is 120 seconds (two minutes) or as set by the ``-w''
575: command line option. \\
576: \end{tabular}
577: \caption{Mount options interpreted by \amd\label{table:pseudo-mount opts}}
578: \end{table}
579:
580: \item[\tt sublink\hfill]
581: the subdirectory within the mounted filesystem to which the reference
582: should point.
583: This can be used to prevent duplicate mounts in cases where multiple
584: directories in the same mounted filesystem are used.
585:
586: \item[\tt type\hfill]
587: the filesystem type to be used. A full description of each
588: type is given in \Ref{filesystems}.
589:
590: \end{list}
591:
592: Superfluous option specifications are ignored and are not reported
593: as errors.
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.