svn commit: r42602 - head/en_US.ISO8859-1/books/handbook/network-servers
Warren Block
wblock at FreeBSD.org
Thu Aug 29 01:46:15 UTC 2013
Author: wblock
Date: Thu Aug 29 01:46:14 2013
New Revision: 42602
URL: http://svnweb.freebsd.org/changeset/doc/42602
Log:
Patch from Ken Reed to update and improve the NFS section. Modified
version of the patch included with PR.
PR: docs/181269
Submitted by: Ken Reed <kreed002 at gmail.com>
Modified:
head/en_US.ISO8859-1/books/handbook/network-servers/chapter.xml
Modified: head/en_US.ISO8859-1/books/handbook/network-servers/chapter.xml
==============================================================================
--- head/en_US.ISO8859-1/books/handbook/network-servers/chapter.xml Thu Aug 29 00:52:20 2013 (r42601)
+++ head/en_US.ISO8859-1/books/handbook/network-servers/chapter.xml Thu Aug 29 01:46:14 2013 (r42602)
@@ -557,37 +557,40 @@ server-program-arguments</programlisting
<title>Network File System (NFS)</title>
<indexterm><primary>NFS</primary></indexterm>
- <para>Among the many different file systems that FreeBSD supports
- is the Network File System, also known as <acronym role="Network
- File System">NFS</acronym>. <acronym role="Network File
- System">NFS</acronym> allows a system to share directories and
- files with others over a network. By using <acronym
- role="Network File System">NFS</acronym>, users and programs can
- access files on remote systems almost as if they were local
- files.</para>
+ <para>&os; supports the Network File System
+ (<acronym>NFS</acronym>), which allows a server to share
+ directories and files with clients over a network. With
+ <acronym>NFS</acronym>, users and programs can access files
+ on remote systems as if they were stored locally.</para>
- <para>Some of the most notable benefits that
- <acronym>NFS</acronym> can provide are:</para>
+ <para>The most notable benefits that
+ <acronym>NFS</acronym> provides are:</para>
<itemizedlist>
<listitem>
- <para>Local workstations use less disk space because commonly
- used data can be stored on a single machine and still remain
- accessible to others over the network.</para>
+ <para>Data that would otherwise be duplicated on each client
+ can be kept in a single location and accessed by clients
+ on the network.</para>
</listitem>
<listitem>
- <para>There is no need for users to have separate home
- directories on every network machine. Home directories
- could be set up on the <acronym>NFS</acronym> server and
- made available throughout the network.</para>
+ <para>User home directories can be stored in one location
+ and accessed by their owners over the network.</para>
</listitem>
<listitem>
- <para>Storage devices such as floppy disks, CDROM drives, and
- &iomegazip; drives can be used by other machines on the
- network. This may reduce the number of removable media
- drives throughout the network.</para>
+ <para>Administration of <acronym>NFS</acronym> exports is
+ also simplified. For example, there is only one file
+ system where security or backup policies must be
+ set.</para>
+ </listitem>
+
+ <listitem>
+ <para>Removable media storage devices, such as floppy disks
+ or <acronym>CD-ROM</acronym> drives, can be used by other
+ machines on the network. This reduces the number of devices
+ throughout the network and provides a centralized location
+ to manage their security.</para>
</listitem>
</itemizedlist>
@@ -600,7 +603,7 @@ server-program-arguments</programlisting
order for this to function properly a few processes have to be
configured and running.</para>
- <para>The server has to be running the following daemons:</para>
+ <para>These daemons must be running on the server:</para>
<indexterm>
<primary>NFS</primary>
<secondary>server</secondary>
@@ -657,13 +660,8 @@ server-program-arguments</programlisting
</tgroup>
</informaltable>
- <para>The client can also run a daemon, known as
- <application>nfsiod</application>. The
- <application>nfsiod</application> daemon services the requests
- from the <acronym>NFS</acronym> server. This is optional, and
- improves performance, but is not required for normal and
- correct operation. See the &man.nfsiod.8; manual page for
- more information.</para>
+ <para>Running &man.nfsiod.8; can improve performance on the
+ client, but is not required.</para>
</sect2>
<sect2 id="network-configuring-nfs">
@@ -674,14 +672,11 @@ server-program-arguments</programlisting
<secondary>configuration</secondary>
</indexterm>
- <para><acronym>NFS</acronym> configuration is a relatively
- straightforward process. The processes that need to be
- running can all start at boot time with a few modifications
- to <filename>/etc/rc.conf</filename>.</para>
-
- <para>On the <acronym>NFS</acronym> server, make sure that the
- following options are configured in the
- <filename>/etc/rc.conf</filename> file:</para>
+ <para>Enabling the <acronym>NFS</acronym> server
+ is straightforward. The required processes
+ can be set to start at boot time by adding
+ these options to
+ <filename>/etc/rc.conf</filename>:</para>
<programlisting>rpcbind_enable="YES"
nfs_server_enable="YES"
@@ -690,99 +685,101 @@ mountd_flags="-r"</programlisting>
<para><application>mountd</application> runs automatically
whenever the <acronym>NFS</acronym> server is enabled.</para>
- <para>On the client, make sure this option is present in
+ <para>To enable the client, set this option in
<filename>/etc/rc.conf</filename>:</para>
<programlisting>nfs_client_enable="YES"</programlisting>
- <para>The <filename>/etc/exports</filename> file specifies which
- file systems <acronym>NFS</acronym> should export (sometimes
- referred to as <quote>share</quote>). Each line in
+ <para><filename>/etc/exports</filename> specifies which
+ file systems the <acronym>NFS</acronym> server will
+ export. Each line in
<filename>/etc/exports</filename> specifies a file system to
- be exported and which machines have access to that file
- system. Along with what machines have access to that file
- system, access options may also be specified. There are many
- such options that can be used in this file but only a few will
- be mentioned here. Other options are discussed in
- the &man.exports.5; manual page.</para>
-
- <para>Here are a few example <filename>/etc/exports</filename>
- entries:</para>
+ be exported and which clients have access to that file system,
+ as well as any access options. There are many
+ such options that can be used in this file, but only a few will
+ be mentioned here. See &man.exports.5; for the full list of
+ options.</para>
<indexterm>
<primary>NFS</primary>
<secondary>export examples</secondary>
</indexterm>
- <para>The following examples give an idea of how to export file
- systems, although the settings may be different depending on
- the environment and network configuration. For instance, to
- export the <filename>/cdrom</filename> directory to three
- example machines that have the same domain name as the server
- (hence the lack of a domain name for each) or have entries in
- the <filename>/etc/hosts</filename> file. The
- <option>-ro</option> flag makes the exported file system
- read-only. With this flag, the remote system will not be able
- to write any changes to the exported file system.</para>
-
- <programlisting>/cdrom -ro host1 host2 host3</programlisting>
-
- <para>The following line exports <filename>/home</filename> to
- three hosts by IP address. This is a useful setup on
- a private network without a <acronym>DNS</acronym> server
- configured. Optionally the <filename>/etc/hosts</filename>
- file could be configured for internal hostnames; please review
- &man.hosts.5; for more information. The
- <option>-alldirs</option> flag allows the subdirectories to be
- mount points. In other words, it will not mount the
- subdirectories but permit the client to mount only the
- directories that are required or needed.</para>
+ <para>These examples give an idea of how to export file systems.
+ Minor modifications may be required for the examples to work
+ on the reader's network.</para>
+
+ <para>This example shows how to export the
+ <filename class="directory">/cdrom</filename> directory to
+ three clients called <replaceable>alpha</replaceable>,
+ <replaceable>bravo</replaceable>, and
+ <replaceable>charlie</replaceable>:</para>
+
+ <programlisting>/cdrom -ro <replaceable>alpha</replaceable> <replaceable>bravo</replaceable> <replaceable>charlie</replaceable></programlisting>
+
+ <para>The <literal>-ro</literal> flag makes the file systems
+ read-only, preventing clients from making any changes to
+ those exported file systems.</para>
+
+ <para>The next example exports
+ <filename class="directory">/home</filename> to three clients
+ by IP address. This can be useful for networks without
+ <acronym>DNS</acronym>. Optionally,
+ <filename>/etc/hosts</filename> could be configured for
+ internal hostnames; please review &man.hosts.5; for more
+ information. The <literal>-alldirs</literal> flag allows
+ subdirectories to be mount points. In other words, it will
+ not mount the subdirectories but permit the client to mount
+ only the directories that are required or needed.</para>
<programlisting>/home -alldirs 10.0.0.2 10.0.0.3 10.0.0.4</programlisting>
- <para>The following line exports <filename>/a</filename> so that
- two clients from different domains may access the file system.
+ <para>This next line exports
+ <filename class="directory">/a</filename> so that two clients
+ from different domains may access the file system.
The <option>-maproot=root</option> flag allows the
<username>root</username> user on the remote system to write
data on the exported file system as <username>root</username>.
If the <literal>-maproot=root</literal> flag is not specified,
- then even if a user has <username>root</username> access on
- the remote system, he will not be able to modify files on
- the exported file system.</para>
+ the client's <username>root</username> user will be mapped
+ to the server's <username>nobody</username> account and will
+ be subject to the access limitations defined for user,
+ <username>nobody</username>.</para>
<programlisting>/a -maproot=root host.example.com box.example.org</programlisting>
- <para>In order for a client to access an exported file system,
- the client must have permission to do so. Make sure the
- client is listed in <filename>/etc/exports</filename>.</para>
-
- <para>In <filename>/etc/exports</filename>, each line represents
- the export information for one file system to one host. A
- remote host can only be specified once per file system, and
- may only have one default entry. For example, assume that
- <filename>/usr</filename> is a single file system. The
- following <filename>/etc/exports</filename> would be
- invalid:</para>
+ <para>For a client to have access to an exported file system,
+ the client must be listed in
+ <filename>/etc/exports</filename>.</para>
+
+ <para>In <filename>/etc/exports</filename>, each line defines
+ the export information for one file system to one or more
+ clients. A remote host can only be specified once per file
+ system. For example, assume that
+ <filename class="directory">/usr</filename> is a single file
+ system. This entry, in <filename>/etc/exports</filename>,
+ would be invalid:</para>
<programlisting># Invalid when /usr is one file system
/usr/src client
/usr/ports client</programlisting>
- <para>One file system, <filename>/usr</filename>, has two lines
+ <para>The <filename class="directory">/usr</filename> file
+ system has two lines
specifying exports to the same host, <hostid>client</hostid>.
The correct format for this situation is:</para>
<programlisting>/usr/src /usr/ports client</programlisting>
- <para>The properties of one file system exported to a given host
- must all occur on one line. Lines without a client specified
- are treated as a single host. This limits how file systems
- may be exported; however, for most environments, this is not
- an issue.</para>
+ <para>The exported file system, its properties, and allowed
+ hosts must occur on a single line. If no clients are listed,
+ then any client on the network may mount the exported file
+ system.</para>
<para>The following is an example of a valid export list, where
- <filename>/usr</filename> and <filename>/exports</filename>
- are local file systems:</para>
+ <filename class="directory">/usr</filename> and
+ <filename class="directory">/exports</filename> are local
+ file systems:</para>
<programlisting># Export src and ports to client01 and client02, but only
# client01 has root privileges on it
@@ -793,24 +790,20 @@ mountd_flags="-r"</programlisting>
/exports -alldirs -maproot=root client01 client02
/exports/obj -ro</programlisting>
- <para>The <application>mountd</application> daemon must be
- forced to recheck the <filename>/etc/exports</filename> file
- whenever it has been modified, so the changes can take effect.
- This can be accomplished either by sending a HUP signal to the
- running daemon:</para>
-
- <screen>&prompt.root; <userinput>kill -HUP `cat /var/run/mountd.pid`</userinput></screen>
-
- <para>or by invoking the <command>mountd</command> &man.rc.8;
- script with the appropriate parameter:</para>
+ <para>The <application>mountd</application> daemon reads
+ <filename>/etc/exports</filename> when started. To make
+ <acronym>NFS</acronym> server changes take effect immediately,
+ force <application>mountd</application> to reread
+ <filename>/etc/exports</filename>:</para>
- <screen>&prompt.root; <userinput>service mountd onereload</userinput></screen>
+ <screen>&prompt.root; <userinput>service mountd reload</userinput></screen>
<para>Please refer to <xref linkend="configtuning-rcd"/> for
more information about using rc scripts.</para>
- <para>NFS services can now be started by running the following
- command, on the <acronym>NFS</acronym> server, as
+ <para>On a new server being configured with
+ <acronym>NFS</acronym> services, the server can be
+ started by running this command as
<username>root</username>:</para>
<screen>&prompt.root; <userinput>service nfsd start</userinput></screen>
@@ -819,12 +812,13 @@ mountd_flags="-r"</programlisting>
<screen>&prompt.root; <userinput>service nfsclient restart</userinput></screen>
- <para>Now everything should be ready to actually mount a remote
- file system. In these examples the server's name will be
- <hostid>server</hostid> and the client's name will be
+ <para>The client now has everything it needs to mount a remote
+ file system. In these examples, the server's name is
+ <hostid>server</hostid> and the client's name is
<hostid>client</hostid>. For testing or to temporarily mount
- a remote file system execute a command like this as
- <username>root</username> on the client:</para>
+ a remote file system, execute
+ <application>mount</application> as
+ <username>root</username> on <hostid>client</hostid>:</para>
<indexterm>
<primary>NFS</primary>
@@ -832,16 +826,20 @@ mountd_flags="-r"</programlisting>
</indexterm>
<screen>&prompt.root; <userinput>mount server:/home /mnt</userinput></screen>
- <para>This will mount the <filename>/home</filename> directory
- on the server at <filename>/mnt</filename> on the client. If
- everything is set up correctly, the server's files should be
- visible and available in the <filename>/mnt</filename>
- directory.</para>
-
- <para>To permanently mount a remote file system each time the
- computer boots, add the file system to the
- <filename>/etc/fstab</filename> file. Here is an
- example:</para>
+ <para>This mounts the
+ <hostid>server</hostid>:
+ <filename class="directory">/home</filename>
+ file system to the
+ <hostid>client</hostid>:
+ <filename class="directory">/mnt</filename> mount
+ point. The files and directories in the
+ <hostid>server</hostid>
+ <filename class="directory">/home</filename> file system will
+ now be available on <hostid>client</hostid>, in the
+ <filename class="directory">/mnt</filename> directory.</para>
+
+ <para>To mount a remote file system each time the client
+ boots, add it to <filename>/etc/fstab</filename>:</para>
<programlisting>server:/home /mnt nfs rw 0 0</programlisting>
@@ -855,32 +853,35 @@ mountd_flags="-r"</programlisting>
<para>Some applications (e.g., <application>mutt</application>)
require file locking to operate correctly. In the case of
<acronym>NFS</acronym>, <application>rpc.lockd</application>
- can be used for file locking. To enable it, add the following
- to the <filename>/etc/rc.conf</filename> file on both client
- and server (it is assumed that the <acronym>NFS</acronym>
- client and server are configured already):</para>
+ can be used for file locking. To enable it, add this line to
+ <filename>/etc/rc.conf</filename> on both client
+ and server:</para>
<programlisting>rpc_lockd_enable="YES"
rpc_statd_enable="YES"</programlisting>
- <para>Start the application by using:</para>
+ <para>Please note that this assumes that both
+ <acronym>NFS</acronym> client and server are already
+ configured.</para>
+
+ <para>Start the application, as
+ <username>root</username>, with:</para>
<screen>&prompt.root; <userinput>service lockd start</userinput>
&prompt.root; <userinput>service statd start</userinput></screen>
- <para>If real locking between the <acronym>NFS</acronym> clients
- and <acronym>NFS</acronym> server is not required, it is
- possible to let the <acronym>NFS</acronym> client do locking
- locally by passing <option>-L</option> to &man.mount.nfs.8;.
- Refer to the &man.mount.nfs.8; manual page for further
- details.</para>
+ <para>If locking is not required on the server, the
+ <acronym>NFS</acronym> client can be configured to
+ lock locally by passing <option>-L</option> to
+ &man.mount.nfs.8;. Refer to the &man.mount.nfs.8;
+ manual page for further details.</para>
</sect2>
<sect2>
<title>Practical Uses</title>
<para><acronym>NFS</acronym> has many practical uses. Some of
- the more common ones are listed below:</para>
+ the more common uses:</para>
<indexterm>
<primary>NFS</primary>
@@ -888,25 +889,26 @@ rpc_statd_enable="YES"</programlisting>
</indexterm>
<itemizedlist>
<listitem>
- <para>Set several machines to share a CDROM or other media
- among them. This is cheaper and often a more convenient
- method to install software on multiple machines.</para>
+ <para>Share a <acronym>CD-ROM</acronym> or other media
+ with any number of clients. It is often more
+ convenient to install software on multiple
+ machines from a single location.</para>
</listitem>
<listitem>
- <para>On large networks, it might be more convenient to
- configure a central <acronym>NFS</acronym> server in which
- to store all the user home directories. These home
- directories can then be exported to the network so that
- users would always have the same home directory,
- regardless of which workstation they log in to.</para>
+ <para>On large networks, it is often more convenient to
+ configure a central <acronym>NFS</acronym> server on which
+ all user home directories are stored. Users can log into
+ a client anywhere on the network and have access to their
+ home directories.</para>
</listitem>
<listitem>
- <para>Several machines could have a common
- <filename>/usr/ports/distfiles</filename> directory. This
- allows for quick access to the source files without
- downloading them on each machine.</para>
+ <para>Several clients may need access to the
+ <filename class="directory">/usr/ports/distfiles</filename>
+ directory. Sharing that directory allows for quick access
+ to the source files without having to download them to
+ each client.</para>
</listitem>
</itemizedlist>
</sect2>
@@ -940,34 +942,37 @@ rpc_statd_enable="YES"</programlisting>
mounts a remote file system whenever a file or directory
within that file system is accessed. Filesystems that are
inactive for a period of time will also be automatically
- unmounted by <application>amd</application>. Using
- <application>amd</application> provides a simple alternative
- to permanent mounts, as permanent mounts are usually listed in
- <filename>/etc/fstab</filename>.</para>
+ unmounted by <application>amd</application>.
+ <application>amd</application> provides an alternative to
+ modifying <filename>/etc/fstab</filename> to list every
+ client.</para>
<para><application>amd</application> operates by attaching
- itself as an NFS server to the <filename>/host</filename> and
- <filename>/net</filename> directories. When a file is
+ itself as an NFS server to the
+ <filename class="directory">/host</filename>
+ and <filename class="directory">/net</filename> directories. When a file is
accessed within one of these directories,
<application>amd</application> looks up the corresponding
remote mount and automatically mounts it.
- <filename>/net</filename> is used to mount an exported file
- system from an IP address, while <filename>/host</filename> is
+ <filename class="directory">/net</filename> is used to mount an exported file
+ system from an IP address, while
+ <filename class="directory">/host</filename> is
used to mount an export from a remote hostname.</para>
- <para>An access to a file within
- <filename>/host/foobar/usr</filename> would tell
- <application>amd</application> to attempt to mount the
- <filename>/usr</filename> export on the host
+ <para>For instance, an attempt to access a file within
+ <filename class="directory">/host/foobar/usr</filename> would tell
+ <application>amd</application> to mount the
+ <filename class="directory">/usr</filename> export on the host
<hostid>foobar</hostid>.</para>
<example>
<title>Mounting an Export with
<application>amd</application></title>
- <para>The <command>showmount</command> command shows the
- available mounts on a remote host. For example, to view the
- mounts of a host named <hostid>foobar</hostid>:</para>
+ <para><command>showmount -e</command> shows the
+ exported file systems that can be mounted from
+ the <acronym>NFS</acronym> server,
+ <hostid>foobar</hostid>:</para>
<screen>&prompt.user; <userinput>showmount -e foobar</userinput>
Exports list on foobar:
@@ -976,155 +981,39 @@ Exports list on foobar:
&prompt.user; <userinput>cd /host/foobar/usr</userinput></screen>
</example>
- <para>As seen in the example, the <command>showmount</command>
- shows <filename>/usr</filename> as an export. When changing
- directories to <filename>/host/foobar/usr</filename>,
- <application>amd</application> attempts to resolve the
- hostname <hostid>foobar</hostid> and automatically mount the
- desired export.</para>
+ <para>The output from <command>showmount</command>
+ shows <filename class="directory">/usr</filename> as an
+ export. When changing directories to
+ <filename class="directory">/host/foobar/usr</filename>,
+ <application>amd</application> intercepts the request and
+ attempts to resolve the hostname <hostid>foobar</hostid>.
+ If successful, <application>amd</application> automatically
+ mounts the desired export.</para>
- <para><application>amd</application> can be started by the
- startup scripts by placing the following lines in
- <filename>/etc/rc.conf</filename>:</para>
+ <para><application>amd</application> is enabled by placing
+ this line in <filename>/etc/rc.conf</filename>:</para>
<programlisting>amd_enable="YES"</programlisting>
- <para>Additionally, custom flags can be passed to
+ <para>It can then be started using the &os; &man.rc.8; scripts
+ or by using the &man.service.8; command.</para>
+
+ <para>Custom flags can be passed to
<application>amd</application> from the
- <varname>amd_flags</varname> option. By default,
- <varname>amd_flags</varname> is set to:</para>
+ <varname>amd_flags</varname> environment variable. By
+ default, <varname>amd_flags</varname> is set to:</para>
<programlisting>amd_flags="-a /.amd_mnt -l syslog /host /etc/amd.map /net /etc/amd.map"</programlisting>
- <para>The <filename>/etc/amd.map</filename> file defines the
- default options that exports are mounted with. The
- <filename>/etc/amd.conf</filename> file defines some of the
+ <para><filename>/etc/amd.map</filename> defines the
+ default options with which exports are mounted.
+ <filename>/etc/amd.conf</filename> defines some of the
more advanced features of
<application>amd</application>.</para>
<para>Consult the &man.amd.8; and &man.amd.conf.5; manual pages
for more information.</para>
</sect2>
-
- <sect2 id="network-nfs-integration">
- <sect2info>
- <authorgroup>
- <author>
- <firstname>John</firstname>
- <surname>Lind</surname>
- <contrib>Contributed by </contrib>
- </author>
- </authorgroup>
- </sect2info>
- <title>Problems Integrating with Other Systems</title>
-
- <para>Certain Ethernet adapters for ISA PC systems have
- limitations which can lead to serious network problems,
- particularly with NFS. This difficulty is not specific to
- FreeBSD, but FreeBSD systems are affected by it.</para>
-
- <para>The problem nearly always occurs when (FreeBSD) PC systems
- are networked with high-performance workstations, such as
- those made by Silicon Graphics, Inc., and Sun Microsystems,
- Inc. The NFS mount will work fine, and some operations may
- succeed, but suddenly the server will seem to become
- unresponsive to the client, even though requests to and from
- other systems continue to be processed. This happens to the
- client system, whether the client is the FreeBSD system or the
- workstation. On many systems, there is no way to shut down
- the client gracefully once this problem has manifested itself.
- The only solution is often to reset the client, because the
- NFS situation cannot be resolved.</para>
-
- <para>Though the <quote>correct</quote> solution is to get a
- higher performance and capacity Ethernet adapter for the
- FreeBSD system, there is a simple workaround that will allow
- satisfactory operation. If the FreeBSD system is the
- <emphasis>server</emphasis>, include the option
- <option>-w=1024</option> on the mount from the client. If the
- FreeBSD system is the <emphasis>client</emphasis>, then mount
- the NFS file system with the option <option>-r=1024</option>.
- These options may be specified using the fourth field of the
- <filename>fstab</filename> entry on the client for automatic
- mounts, or by using the <option>-o</option> parameter of the
- &man.mount.8; command for manual mounts.</para>
-
- <para>It should be noted that there is a different problem,
- sometimes mistaken for this one, when the NFS servers and
- clients are on different networks. If that is the case, make
- <emphasis>certain</emphasis> that the routers are routing the
- necessary <acronym>UDP</acronym> information.</para>
-
- <para>In the following examples, <hostid>fastws</hostid> is the
- host (interface) name of a high-performance workstation, and
- <hostid>freebox</hostid> is the host (interface) name of a
- FreeBSD system with a lower-performance Ethernet adapter.
- Also, <filename>/sharedfs</filename> will be the exported NFS
- file system (see &man.exports.5;), and
- <filename>/project</filename> will be the mount point on the
- client for the exported file system. In all cases, note that
- additional options, such as <option>hard</option> or
- <option>soft</option> and <option>bg</option> may be desirable
- in the application.</para>
-
- <para>Examples for the FreeBSD system (<hostid>freebox</hostid>)
- as the client in <filename>/etc/fstab</filename> on
- <hostid>freebox</hostid>:</para>
-
- <programlisting>fastws:/sharedfs /project nfs rw,-r=1024 0 0</programlisting>
-
- <para>As a manual mount command on
- <hostid>freebox</hostid>:</para>
-
- <screen>&prompt.root; <userinput>mount -t nfs -o -r=1024 fastws:/sharedfs /project</userinput></screen>
-
- <para>Examples for the FreeBSD system as the server in
- <filename>/etc/fstab</filename> on
- <hostid>fastws</hostid>:</para>
-
- <programlisting>freebox:/sharedfs /project nfs rw,-w=1024 0 0</programlisting>
-
- <para>As a manual mount command on
- <hostid>fastws</hostid>:</para>
-
- <screen>&prompt.root; <userinput>mount -t nfs -o -w=1024 freebox:/sharedfs /project</userinput></screen>
-
- <para>Nearly any 16-bit Ethernet adapter will allow operation
- without the above restrictions on the read or write
- size.</para>
-
- <para>For anyone who cares, here is what happens when the
- failure occurs, which also explains why it is unrecoverable.
- NFS typically works with a <quote>block</quote> size of
- 8 K (though it may do fragments of smaller sizes). Since
- the maximum Ethernet packet is around 1500 bytes, the NFS
- <quote>block</quote> gets split into multiple Ethernet
- packets, even though it is still a single unit to the
- upper-level code, and must be received, assembled, and
- <emphasis>acknowledged</emphasis> as a unit. The
- high-performance workstations can pump out the packets which
- comprise the NFS unit one right after the other, just as close
- together as the standard allows. On the smaller, lower
- capacity cards, the later packets overrun the earlier packets
- of the same unit before they can be transferred to the host
- and the unit as a whole cannot be reconstructed or
- acknowledged. As a result, the workstation will time out and
- try again, but it will try again with the entire 8 K
- unit, and the process will be repeated, ad infinitum.</para>
-
- <para>By keeping the unit size below the Ethernet packet size
- limitation, we ensure that any complete Ethernet packet
- received can be acknowledged individually, avoiding the
- deadlock situation.</para>
-
- <para>Overruns may still occur when a high-performance
- workstations is slamming data out to a PC system, but with the
- better cards, such overruns are not guaranteed on NFS
- <quote>units</quote>. When an overrun occurs, the units
- affected will be retransmitted, and there will be a fair
- chance that they will be received, assembled, and
- acknowledged.</para>
- </sect2>
</sect1>
<sect1 id="network-nis">
More information about the svn-doc-head
mailing list