os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Patch from Ken Reed to update and improve the NFS section. Modified

Browse source 
version of the patch included with PR.

PR:		docs/181269
Submitted by:	Ken Reed <kreed002@gmail.com>
This commit is contained in:
Warren Block 2013-08-29 01:46:14 +00:00
parent 7b067ac76b
commit eda432163d
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=42602
1 changed files with 185 additions and 296 deletions
Download patch file Download diff file Expand all files Collapse all files

481
en_US.ISO8859-1/books/handbook/network-servers/chapter.xml
View file

@ -557,37 +557,40 @@ server-program-arguments</programlisting>
<title>Network File System (NFS)</title> <title>Network File System (NFS)</title>
<indexterm><primary>NFS</primary></indexterm> <indexterm><primary>NFS</primary></indexterm>
<para>Among the many different file systems that FreeBSD supports <para>&os; supports the Network File System
is the Network File System, also known as <acronym role="Network (<acronym>NFS</acronym>), which allows a server to share
File System">NFS</acronym>. <acronym role="Network File directories and files with clients over a network. With
System">NFS</acronym> allows a system to share directories and <acronym>NFS</acronym>, users and programs can access files
files with others over a network. By using <acronym on remote systems as if they were stored locally.</para>
role="Network File System">NFS</acronym>, users and programs can
access files on remote systems almost as if they were local
files.</para>
<para>Some of the most notable benefits that <para>The most notable benefits that
<acronym>NFS</acronym> can provide are:</para> <acronym>NFS</acronym> provides are:</para>
<itemizedlist> <itemizedlist>
<listitem> <listitem>
<para>Local workstations use less disk space because commonly <para>Data that would otherwise be duplicated on each client
used data can be stored on a single machine and still remain can be kept in a single location and accessed by clients
accessible to others over the network.</para> on the network.</para>
</listitem> </listitem>
<listitem> <listitem>
<para>There is no need for users to have separate home <para>User home directories can be stored in one location
directories on every network machine. Home directories and accessed by their owners over the network.</para>
could be set up on the <acronym>NFS</acronym> server and
made available throughout the network.</para>
</listitem> </listitem>
<listitem> <listitem>
<para>Storage devices such as floppy disks, CDROM drives, and <para>Administration of <acronym>NFS</acronym> exports is
&iomegazip; drives can be used by other machines on the also simplified. For example, there is only one file
network. This may reduce the number of removable media system where security or backup policies must be
drives throughout the network.</para> 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> </listitem>
</itemizedlist> </itemizedlist>
@ -600,7 +603,7 @@ server-program-arguments</programlisting>
order for this to function properly a few processes have to be order for this to function properly a few processes have to be
configured and running.</para> 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> <indexterm>
<primary>NFS</primary> <primary>NFS</primary>
<secondary>server</secondary> <secondary>server</secondary>
@ -657,13 +660,8 @@ server-program-arguments</programlisting>
</tgroup> </tgroup>
</informaltable> </informaltable>
<para>The client can also run a daemon, known as <para>Running &man.nfsiod.8; can improve performance on the
<application>nfsiod</application>. The client, but is not required.</para>
<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>
</sect2> </sect2>
<sect2 id="network-configuring-nfs"> <sect2 id="network-configuring-nfs">
@ -674,14 +672,11 @@ server-program-arguments</programlisting>
<secondary>configuration</secondary> <secondary>configuration</secondary>
</indexterm> </indexterm>
<para><acronym>NFS</acronym> configuration is a relatively <para>Enabling the <acronym>NFS</acronym> server
straightforward process. The processes that need to be is straightforward. The required processes
running can all start at boot time with a few modifications can be set to start at boot time by adding
to <filename>/etc/rc.conf</filename>.</para> these options 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>
<programlisting>rpcbind_enable="YES" <programlisting>rpcbind_enable="YES"
nfs_server_enable="YES" nfs_server_enable="YES"
@ -690,99 +685,101 @@ mountd_flags="-r"</programlisting>
<para><application>mountd</application> runs automatically <para><application>mountd</application> runs automatically
whenever the <acronym>NFS</acronym> server is enabled.</para> 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> <filename>/etc/rc.conf</filename>:</para>
<programlisting>nfs_client_enable="YES"</programlisting> <programlisting>nfs_client_enable="YES"</programlisting>
<para>The <filename>/etc/exports</filename> file specifies which <para><filename>/etc/exports</filename> specifies which
file systems <acronym>NFS</acronym> should export (sometimes file systems the <acronym>NFS</acronym> server will
referred to as <quote>share</quote>). Each line in export. Each line in
<filename>/etc/exports</filename> specifies a file system to <filename>/etc/exports</filename> specifies a file system to
be exported and which machines have access to that file be exported and which clients have access to that file system,
system. Along with what machines have access to that file as well as any access options. There are many
system, access options may also be specified. There are many such options that can be used in this file, but only a few will
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
be mentioned here. Other options are discussed in options.</para>
the &man.exports.5; manual page.</para>
<para>Here are a few example <filename>/etc/exports</filename>
entries:</para>
<indexterm> <indexterm>
<primary>NFS</primary> <primary>NFS</primary>
<secondary>export examples</secondary> <secondary>export examples</secondary>
</indexterm> </indexterm>
<para>The following examples give an idea of how to export file <para>These examples give an idea of how to export file systems.
systems, although the settings may be different depending on Minor modifications may be required for the examples to work
the environment and network configuration. For instance, to on the reader's network.</para>
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>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>
<para>The following line exports <filename>/home</filename> to <programlisting>/cdrom -ro <replaceable>alpha</replaceable> <replaceable>bravo</replaceable> <replaceable>charlie</replaceable></programlisting>
three hosts by IP address. This is a useful setup on
a private network without a <acronym>DNS</acronym> server <para>The <literal>-ro</literal> flag makes the file systems
configured. Optionally the <filename>/etc/hosts</filename> read-only, preventing clients from making any changes to
file could be configured for internal hostnames; please review those exported file systems.</para>
&man.hosts.5; for more information. The
<option>-alldirs</option> flag allows the subdirectories to be <para>The next example exports
mount points. In other words, it will not mount the <filename class="directory">/home</filename> to three clients
subdirectories but permit the client to mount only the by IP address. This can be useful for networks without
directories that are required or needed.</para> <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> <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 <para>This next line exports
two clients from different domains may access the file system. <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 The <option>-maproot=root</option> flag allows the
<username>root</username> user on the remote system to write <username>root</username> user on the remote system to write
data on the exported file system as <username>root</username>. data on the exported file system as <username>root</username>.
If the <literal>-maproot=root</literal> flag is not specified, If the <literal>-maproot=root</literal> flag is not specified,
then even if a user has <username>root</username> access on the client's <username>root</username> user will be mapped
the remote system, he will not be able to modify files on to the server's <username>nobody</username> account and will
the exported file system.</para> be subject to the access limitations defined for user,
<username>nobody</username>.</para>
<programlisting>/a -maproot=root host.example.com box.example.org</programlisting> <programlisting>/a -maproot=root host.example.com box.example.org</programlisting>
<para>In order for a client to access an exported file system, <para>For a client to have access to an exported file system,
the client must have permission to do so. Make sure the the client must be listed in
client is listed in <filename>/etc/exports</filename>.</para> <filename>/etc/exports</filename>.</para>
<para>In <filename>/etc/exports</filename>, each line represents <para>In <filename>/etc/exports</filename>, each line defines
the export information for one file system to one host. A the export information for one file system to one or more
remote host can only be specified once per file system, and clients. A remote host can only be specified once per file
may only have one default entry. For example, assume that system. For example, assume that
<filename>/usr</filename> is a single file system. The <filename class="directory">/usr</filename> is a single file
following <filename>/etc/exports</filename> would be system. This entry, in <filename>/etc/exports</filename>,
invalid:</para> would be invalid:</para>
<programlisting># Invalid when /usr is one file system <programlisting># Invalid when /usr is one file system
/usr/src client /usr/src client
/usr/ports client</programlisting> /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>. specifying exports to the same host, <hostid>client</hostid>.
The correct format for this situation is:</para> The correct format for this situation is:</para>
<programlisting>/usr/src /usr/ports client</programlisting> <programlisting>/usr/src /usr/ports client</programlisting>
<para>The properties of one file system exported to a given host <para>The exported file system, its properties, and allowed
must all occur on one line. Lines without a client specified hosts must occur on a single line. If no clients are listed,
are treated as a single host. This limits how file systems then any client on the network may mount the exported file
may be exported; however, for most environments, this is not system.</para>
an issue.</para>
<para>The following is an example of a valid export list, where <para>The following is an example of a valid export list, where
<filename>/usr</filename> and <filename>/exports</filename> <filename class="directory">/usr</filename> and
are local file systems:</para> <filename class="directory">/exports</filename> are local
file systems:</para>
<programlisting># Export src and ports to client01 and client02, but only <programlisting># Export src and ports to client01 and client02, but only
# client01 has root privileges on it # client01 has root privileges on it
@ -793,24 +790,20 @@ mountd_flags="-r"</programlisting>
/exports -alldirs -maproot=root client01 client02 /exports -alldirs -maproot=root client01 client02
/exports/obj -ro</programlisting> /exports/obj -ro</programlisting>
<para>The <application>mountd</application> daemon must be <para>The <application>mountd</application> daemon reads
forced to recheck the <filename>/etc/exports</filename> file <filename>/etc/exports</filename> when started. To make
whenever it has been modified, so the changes can take effect. <acronym>NFS</acronym> server changes take effect immediately,
This can be accomplished either by sending a HUP signal to the force <application>mountd</application> to reread
running daemon:</para> <filename>/etc/exports</filename>:</para>
<screen>&prompt.root; <userinput>kill -HUP `cat /var/run/mountd.pid`</userinput></screen> <screen>&prompt.root; <userinput>service mountd reload</userinput></screen>
<para>or by invoking the <command>mountd</command> &man.rc.8;
script with the appropriate parameter:</para>
<screen>&prompt.root; <userinput>service mountd onereload</userinput></screen>
<para>Please refer to <xref linkend="configtuning-rcd"/> for <para>Please refer to <xref linkend="configtuning-rcd"/> for
more information about using rc scripts.</para> more information about using rc scripts.</para>
<para>NFS services can now be started by running the following <para>On a new server being configured with
command, on the <acronym>NFS</acronym> server, as <acronym>NFS</acronym> services, the server can be
started by running this command as
<username>root</username>:</para> <username>root</username>:</para>
<screen>&prompt.root; <userinput>service nfsd start</userinput></screen> <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> <screen>&prompt.root; <userinput>service nfsclient restart</userinput></screen>
<para>Now everything should be ready to actually mount a remote <para>The client now has everything it needs to mount a remote
file system. In these examples the server's name will be file system. In these examples, the server's name is
<hostid>server</hostid> and the client's name will be <hostid>server</hostid> and the client's name is
<hostid>client</hostid>. For testing or to temporarily mount <hostid>client</hostid>. For testing or to temporarily mount
a remote file system execute a command like this as a remote file system, execute
<username>root</username> on the client:</para> <application>mount</application> as
<username>root</username> on <hostid>client</hostid>:</para>
<indexterm> <indexterm>
<primary>NFS</primary> <primary>NFS</primary>
@ -832,16 +826,20 @@ mountd_flags="-r"</programlisting>
</indexterm> </indexterm>
<screen>&prompt.root; <userinput>mount server:/home /mnt</userinput></screen> <screen>&prompt.root; <userinput>mount server:/home /mnt</userinput></screen>
<para>This will mount the <filename>/home</filename> directory <para>This mounts the
on the server at <filename>/mnt</filename> on the client. If <hostid>server</hostid>:
everything is set up correctly, the server's files should be <filename class="directory">/home</filename>
visible and available in the <filename>/mnt</filename> file system to the
directory.</para> <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 permanently mount a remote file system each time the <para>To mount a remote file system each time the client
computer boots, add the file system to the boots, add it to <filename>/etc/fstab</filename>:</para>
<filename>/etc/fstab</filename> file. Here is an
example:</para>
<programlisting>server:/home /mnt nfs rw 0 0</programlisting> <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>) <para>Some applications (e.g., <application>mutt</application>)
require file locking to operate correctly. In the case of require file locking to operate correctly. In the case of
<acronym>NFS</acronym>, <application>rpc.lockd</application> <acronym>NFS</acronym>, <application>rpc.lockd</application>
can be used for file locking. To enable it, add the following can be used for file locking. To enable it, add this line to
to the <filename>/etc/rc.conf</filename> file on both client <filename>/etc/rc.conf</filename> on both client
and server (it is assumed that the <acronym>NFS</acronym> and server:</para>
client and server are configured already):</para>
<programlisting>rpc_lockd_enable="YES" <programlisting>rpc_lockd_enable="YES"
rpc_statd_enable="YES"</programlisting> 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> <screen>&prompt.root; <userinput>service lockd start</userinput>
&prompt.root; <userinput>service statd start</userinput></screen> &prompt.root; <userinput>service statd start</userinput></screen>
<para>If real locking between the <acronym>NFS</acronym> clients <para>If locking is not required on the server, the
and <acronym>NFS</acronym> server is not required, it is <acronym>NFS</acronym> client can be configured to
possible to let the <acronym>NFS</acronym> client do locking lock locally by passing <option>-L</option> to
locally by passing <option>-L</option> to &man.mount.nfs.8;. &man.mount.nfs.8;. Refer to the &man.mount.nfs.8;
Refer to the &man.mount.nfs.8; manual page for further manual page for further details.</para>
details.</para>
</sect2> </sect2>
<sect2> <sect2>
<title>Practical Uses</title> <title>Practical Uses</title>
<para><acronym>NFS</acronym> has many practical uses. Some of <para><acronym>NFS</acronym> has many practical uses. Some of
the more common ones are listed below:</para> the more common uses:</para>
<indexterm> <indexterm>
<primary>NFS</primary> <primary>NFS</primary>
@ -888,25 +889,26 @@ rpc_statd_enable="YES"</programlisting>
</indexterm> </indexterm>
<itemizedlist> <itemizedlist>
<listitem> <listitem>
<para>Set several machines to share a CDROM or other media <para>Share a <acronym>CD-ROM</acronym> or other media
among them. This is cheaper and often a more convenient with any number of clients. It is often more
method to install software on multiple machines.</para> convenient to install software on multiple
machines from a single location.</para>
</listitem> </listitem>
<listitem> <listitem>
<para>On large networks, it might be more convenient to <para>On large networks, it is often more convenient to
configure a central <acronym>NFS</acronym> server in which configure a central <acronym>NFS</acronym> server on which
to store all the user home directories. These home all user home directories are stored. Users can log into
directories can then be exported to the network so that a client anywhere on the network and have access to their
users would always have the same home directory, home directories.</para>
regardless of which workstation they log in to.</para>
</listitem> </listitem>
<listitem> <listitem>
<para>Several machines could have a common <para>Several clients may need access to the
<filename>/usr/ports/distfiles</filename> directory. This <filename class="directory">/usr/ports/distfiles</filename>
allows for quick access to the source files without directory. Sharing that directory allows for quick access
downloading them on each machine.</para> to the source files without having to download them to
each client.</para>
</listitem> </listitem>
</itemizedlist> </itemizedlist>
</sect2> </sect2>
@ -940,34 +942,37 @@ rpc_statd_enable="YES"</programlisting>
mounts a remote file system whenever a file or directory mounts a remote file system whenever a file or directory
within that file system is accessed. Filesystems that are within that file system is accessed. Filesystems that are
inactive for a period of time will also be automatically inactive for a period of time will also be automatically
unmounted by <application>amd</application>. Using unmounted by <application>amd</application>.
<application>amd</application> provides a simple alternative <application>amd</application> provides an alternative to
to permanent mounts, as permanent mounts are usually listed in modifying <filename>/etc/fstab</filename> to list every
<filename>/etc/fstab</filename>.</para> client.</para>
<para><application>amd</application> operates by attaching <para><application>amd</application> operates by attaching
itself as an NFS server to the <filename>/host</filename> and itself as an NFS server to the
<filename>/net</filename> directories. When a file is <filename class="directory">/host</filename>
and <filename class="directory">/net</filename> directories. When a file is
accessed within one of these directories, accessed within one of these directories,
<application>amd</application> looks up the corresponding <application>amd</application> looks up the corresponding
remote mount and automatically mounts it. remote mount and automatically mounts it.
<filename>/net</filename> is used to mount an exported file <filename class="directory">/net</filename> is used to mount an exported file
system from an IP address, while <filename>/host</filename> is system from an IP address, while
<filename class="directory">/host</filename> is
used to mount an export from a remote hostname.</para> used to mount an export from a remote hostname.</para>
<para>An access to a file within <para>For instance, an attempt to access a file within
<filename>/host/foobar/usr</filename> would tell <filename class="directory">/host/foobar/usr</filename> would tell
<application>amd</application> to attempt to mount the <application>amd</application> to mount the
<filename>/usr</filename> export on the host <filename class="directory">/usr</filename> export on the host
<hostid>foobar</hostid>.</para> <hostid>foobar</hostid>.</para>
<example> <example>
<title>Mounting an Export with <title>Mounting an Export with
<application>amd</application></title> <application>amd</application></title>
<para>The <command>showmount</command> command shows the <para><command>showmount -e</command> shows the
available mounts on a remote host. For example, to view the exported file systems that can be mounted from
mounts of a host named <hostid>foobar</hostid>:</para> the <acronym>NFS</acronym> server,
<hostid>foobar</hostid>:</para>
<screen>&prompt.user; <userinput>showmount -e foobar</userinput> <screen>&prompt.user; <userinput>showmount -e foobar</userinput>
Exports list on foobar: Exports list on foobar:
@ -976,155 +981,39 @@ Exports list on foobar:
&prompt.user; <userinput>cd /host/foobar/usr</userinput></screen> &prompt.user; <userinput>cd /host/foobar/usr</userinput></screen>
</example> </example>
<para>As seen in the example, the <command>showmount</command> <para>The output from <command>showmount</command>
shows <filename>/usr</filename> as an export. When changing shows <filename class="directory">/usr</filename> as an
directories to <filename>/host/foobar/usr</filename>, export. When changing directories to
<application>amd</application> attempts to resolve the <filename class="directory">/host/foobar/usr</filename>,
hostname <hostid>foobar</hostid> and automatically mount the <application>amd</application> intercepts the request and
desired export.</para> 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 <para><application>amd</application> is enabled by placing
startup scripts by placing the following lines in this line in <filename>/etc/rc.conf</filename>:</para>
<filename>/etc/rc.conf</filename>:</para>
<programlisting>amd_enable="YES"</programlisting> <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 <application>amd</application> from the
<varname>amd_flags</varname> option. By default, <varname>amd_flags</varname> environment variable. By
<varname>amd_flags</varname> is set to:</para> 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> <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 <para><filename>/etc/amd.map</filename> defines the
default options that exports are mounted with. The default options with which exports are mounted.
<filename>/etc/amd.conf</filename> file defines some of the <filename>/etc/amd.conf</filename> defines some of the
more advanced features of more advanced features of
<application>amd</application>.</para> <application>amd</application>.</para>
<para>Consult the &man.amd.8; and &man.amd.conf.5; manual pages <para>Consult the &man.amd.8; and &man.amd.conf.5; manual pages
for more information.</para> for more information.</para>
</sect2> </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&nbsp;K (though it may do fragments of smaller sizes). Since
the maximum Ethernet packet is around 1500&nbsp;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&nbsp;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>
<sect1 id="network-nis"> <sect1 id="network-nis">