old-www/LDP/nag2/x-087-2-nfs.mountd.html

532 lines
9.7 KiB
HTML

<HTML
><HEAD
><TITLE
>Mounting an NFS Volume</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.57"><LINK
REL="HOME"
TITLE="Linux Network Administrators Guide"
HREF="index.html"><LINK
REL="UP"
TITLE="The NetworkFile System"
HREF="x-087-2-nfs.html"><LINK
REL="PREVIOUS"
TITLE="Preparing NFS"
HREF="x-087-2-nfs.nfsd.html"><LINK
REL="NEXT"
TITLE="The NFS Daemons"
HREF="x-087-2-nfs.daemons.html"></HEAD
><BODY
CLASS="SECT1"
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#840084"
ALINK="#0000FF"
><DIV
CLASS="NAVHEADER"
><TABLE
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="3"
ALIGN="center"
>Linux Network Administrators Guide</TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="bottom"
><A
HREF="x-087-2-nfs.nfsd.html"
>Prev</A
></TD
><TD
WIDTH="80%"
ALIGN="center"
VALIGN="bottom"
>Chapter 14. The NetworkFile System</TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="bottom"
><A
HREF="x-087-2-nfs.daemons.html"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="SECT1"
><H1
CLASS="SECT1"
><A
NAME="X-087-2-NFS.MOUNTD"
>14.2. Mounting an NFS Volume</A
></H1
><P
>&#13;
The mounting of NFS volumes closely resembles regular file
systems. Invoke <B
CLASS="COMMAND"
>mount</B
> using the following syntax:<A
NAME="X-087-2-FNNF05"
HREF="#FTN.X-087-2-FNNF05"
>[1]</A
>
<TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="SCREEN"
># <TT
CLASS="USERINPUT"
><B
>mount -t nfs</B
></TT
> <TT
CLASS="REPLACEABLE"
><I
>nfs_volume local_dir options</I
></TT
> </PRE
></TD
></TR
></TABLE
></P
><P
><TT
CLASS="REPLACEABLE"
><I
>nfs_volume</I
></TT
> is given as
<TT
CLASS="REPLACEABLE"
><I
>remote_host</I
></TT
>:<TT
CLASS="REPLACEABLE"
><I
>remote_dir</I
></TT
>.
Since this notation is unique to NFS filesystems, you can leave out
the <TT
CLASS="OPTION"
>&#8211;t nfs</TT
> option.</P
><P
>&#13;There are a number of additional options that you can specify to
<B
CLASS="COMMAND"
>mount</B
> upon mounting an NFS volume. These may be
given either following the <TT
CLASS="OPTION"
>&#8211;o</TT
> switch on the
command line or in the options field of the
<TT
CLASS="FILENAME"
>/etc/fstab</TT
> entry for the volume. In both cases,
multiple options are separated by commas and must not
contain any whitespace characters. Options specified on the command
line always override those given in the <TT
CLASS="FILENAME"
>fstab</TT
>
file.</P
><P
>Here is a sample entry from <TT
CLASS="FILENAME"
>/etc/fstab</TT
>&#8201;:
<TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="SCREEN"
># volume mount point type options
news:/var/spool/news /var/spool/news nfs timeo=14,intr</PRE
></TD
></TR
></TABLE
></P
><P
>This volume can then be mounted using this command:
<TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="SCREEN"
># <TT
CLASS="USERINPUT"
><B
>mount news:/var/spool/news</B
></TT
></PRE
></TD
></TR
></TABLE
></P
><P
>In the absence of an <TT
CLASS="FILENAME"
>fstab</TT
> entry, NFS
<B
CLASS="COMMAND"
>mount</B
> invocations look a lot uglier. For instance,
suppose you mount your users' home directories from a machine named
<SPAN
CLASS="SYSTEMITEM"
>moonshot</SPAN
>, which uses a default
block size of 4 K for read/write operations. You might increase the
block size to 8 K to obtain better performance by issuing the command:
<TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="SCREEN"
># <TT
CLASS="USERINPUT"
><B
>mount moonshot:/home /home -o rsize=8192,wsize=8192</B
></TT
></PRE
></TD
></TR
></TABLE
></P
><P
>&#13;The list of all valid options is described in its entirety in the
<TT
CLASS="FILENAME"
>nfs(5)</TT
> manual page. The following is a partial list
of options you would probably want to use:
<P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
><I
CLASS="EMPHASIS"
>rsize=n</I
> and <I
CLASS="EMPHASIS"
>wsize=n</I
></DT
><DD
><P
>These specify the datagram size used by the NFS clients on read and write
requests, respectively. The default depends on the version of kernel, but
is normally 1,024 bytes.</P
></DD
><DT
><I
CLASS="EMPHASIS"
>timeo=n</I
></DT
><DD
><P
>This sets the time (in tenths of a second) the NFS client will wait for a
request to complete. The default value is 7 (0.7 seconds). What happens after
a timeout depends on whether you use the <I
CLASS="EMPHASIS"
>hard</I
> or
<I
CLASS="EMPHASIS"
>soft</I
> option.</P
></DD
><DT
><I
CLASS="EMPHASIS"
>hard</I
></DT
><DD
><P
>Explicitly mark this volume as hard-mounted. This is on by default.
This option causes the server to report a message to the console when a
major timeout occurs and continues trying indefinitely.</P
></DD
><DT
><I
CLASS="EMPHASIS"
>soft</I
></DT
><DD
><P
>Soft-mount (as opposed to hard-mount) the driver. This option causes
an I/O error to be reported to the process attempting a file operation when
a major timeout occurs.</P
></DD
><DT
><I
CLASS="EMPHASIS"
>intr</I
></DT
><DD
><P
>Allow signals to interrupt an NFS call. Useful for aborting when the
server doesn't respond.</P
></DD
></DL
></DIV
></P
><P
>Except for <I
CLASS="EMPHASIS"
>rsize</I
> and <I
CLASS="EMPHASIS"
>wsize</I
>, all of these options
apply to the client's behavior if the server should become temporarily
inaccessible. They work together in the following way: Whenever the
client sends a request to the NFS server, it expects the operation to
have finished after a given interval (specified in the
<I
CLASS="EMPHASIS"
>timeout</I
> option). If no confirmation
is received within this time, a so-called <I
CLASS="EMPHASIS"
>minor timeout</I
>
occurs, and the operation is retried with the timeout interval doubled. After
reaching a maximum timeout of 60 seconds, a <I
CLASS="EMPHASIS"
>major timeout</I
>
occurs.</P
><P
>&#13;
By default, a major timeout causes the client to print a message
to the console and start all over again, this time with an initial
timeout interval twice that of the previous cascade. Potentially, this
may go on forever. Volumes that stubbornly retry an operation until
the server becomes available again are called
<I
CLASS="EMPHASIS"
>hard-mounted</I
>. The opposite variety, called
<I
CLASS="EMPHASIS"
>soft-mounted</I
>, generate an I/O error for the
calling process whenever a major timeout occurs. Because of the
write-behind introduced by the buffer cache, this error condition is
not propagated to the process itself before it calls the
<TT
CLASS="FUNCTION"
>write</TT
> function the next time, so a program can
never be sure that a write operation to a soft-mounted volume has
succeeded at all.</P
><P
>Whether you hard- or soft-mount a volume depends partly on taste but
also on the type of information you want to access from a volume. For
example, if you mount your X programs by NFS, you certainly would not
want your X session to go berserk just because someone brought the
network to a grinding halt by firing up seven copies of Doom at the
same time or by pulling the Ethernet plug for a moment. By
hard-mounting the directory containing these programs, you make sure
that your computer waits until it is able to re-establish contact
with your NFS server. On the other hand, non-critical data such as
NFS-mounted news partitions or FTP archives may also be
soft-mounted, so if the remote machine is temporarily unreachable or
down, it doesn't hang your session. If your network connection to the
server is flaky or goes through a loaded router, you may either
increase the initial timeout using the <I
CLASS="EMPHASIS"
>timeo</I
> option or hard-mount the
volumes. NFS volumes are hard-mounted by default.</P
><P
>Hard mounts present a problem because, by default, the file operations
are not interruptible. Thus, if a process attempts, for example, a
write to a remote server and that server is unreachable, the user's
application hangs and the user can't do anything to abort the
operation. If you use the <I
CLASS="EMPHASIS"
>intr</I
>
option in conjuction with a hard mount, any signals received by the
process interrupt the NFS call so that users can still abort
hanging file accesses and resume work (although without saving the
file).</P
><P
>Usually, the <B
CLASS="COMMAND"
>rpc.mountd</B
> daemon in some way or other
keeps track of which directories have been mounted by what hosts. This
information can be displayed using the <B
CLASS="COMMAND"
>showmount</B
>
program, which is also included in the NFS server package:
<TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="SCREEN"
># <TT
CLASS="USERINPUT"
><B
>showmount -e moonshot</B
></TT
>
Export list for localhost:
/home &#60;anon clnt&#62;
# <TT
CLASS="USERINPUT"
><B
>showmount -d moonshot</B
></TT
>
Directories on localhost:
/home
# <TT
CLASS="USERINPUT"
><B
>showmount -a moonshot</B
></TT
>
All mount points on localhost:
localhost:/home</PRE
></TD
></TR
></TABLE
></P
></DIV
><H3
CLASS="FOOTNOTES"
>Notes</H3
><TABLE
BORDER="0"
CLASS="FOOTNOTES"
WIDTH="100%"
><TR
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="5%"
><A
NAME="FTN.X-087-2-FNNF05"
HREF="x-087-2-nfs.mountd.html#X-087-2-FNNF05"
>[1]</A
></TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="95%"
><P
> One doesn't say filesystem
because these are not proper filesystems.</P
></TD
></TR
></TABLE
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="x-087-2-nfs.nfsd.html"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="index.html"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="x-087-2-nfs.daemons.html"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>Preparing NFS</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="x-087-2-nfs.html"
>Up</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>The NFS Daemons</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>