<chapter id="chapter3-1"><title>NFS Tunable Parameters</title><highlights><para>This section describes the NFS tunable parameters.</para><itemizedlist><listitem><para><olink targetptr="chapter3-2" remap="internal">Tuning the NFS Environment</olink></para>
</listitem><listitem><para><olink targetptr="chapter3-3" remap="internal">NFS Module Parameters</olink></para>
</listitem><listitem><para><olink targetptr="chapter3-22" remap="internal">nfssrv Module Parameters</olink></para>
</listitem><listitem><para><olink targetptr="chapter3-27" remap="internal">rpcmod Module Parameters</olink></para>
</listitem>
</itemizedlist>
</highlights><sect1 id="chapter3-23"><title>Where to Find Tunable Parameter Information</title><informaltable frame="topbot"><tgroup cols="2" colsep="0" rowsep="0"><colspec colname="colspec0" colwidth="50*"/><colspec colname="colspec1" colwidth="50*"/><thead><row rowsep="1"><entry><para>Tunable Parameter</para>
</entry><entry><para>For Information</para>
</entry>
</row>
</thead><tbody><row><entry><para>Solaris kernel tunables</para>
</entry><entry><para><olink targetptr="chapter2-1" remap="internal">Chapter&nbsp;2, Solaris Kernel Tunable
Parameters</olink></para>
</entry>
</row><row><entry><para>Internet Protocol Suite tunable parameters</para>
</entry><entry><para><olink targetptr="chapter4-1" remap="internal">Chapter&nbsp;4, Internet Protocol Suite
Tunable Parameters</olink></para>
</entry>
</row><row><entry><para>Network Cache and Accelerator (NCA) tunable parameters</para>
</entry><entry><para><olink targetptr="chapter5-1" remap="internal">Chapter&nbsp;5, Network Cache and Accelerator
Tunable Parameters</olink></para>
</entry>
</row>
</tbody>
</tgroup>
</informaltable>
</sect1><sect1 id="chapter3-2"><title>Tuning the NFS Environment</title><para>You can define NFS parameters in the <literal>/etc/system</literal> file,
which is read during the boot process. Each parameter includes the name of
its associated kernel module. For more information, see <olink targetptr="chapter1-2" remap="internal">Tuning a Solaris System</olink>.</para><caution><para>The names of the parameters, the modules that they reside in,
and the default values can change between releases. Check the documentation
for the version of the active SunOS release before making changes or applying
values from previous releases.</para>
</caution>
</sect1><sect1 id="chapter3-3"><title>NFS Module Parameters</title><para>This section describes parameters related to the NFS kernel module.</para><sect2 id="chapter3-42"><title><literal>nfs:nfs3_pathconf_disable_cache</literal></title><variablelist><varlistentry><term>Description</term><listitem><para>Controls the caching of <literal>pathconf</literal> information
for NFS Version 3 mounted file systems.</para>
</listitem>
</varlistentry><varlistentry><term>Data Type</term><listitem><para>Integer (32-bit)</para>
</listitem>
</varlistentry><varlistentry><term>Default</term><listitem><para>0 (caching enabled)</para>
</listitem>
</varlistentry><varlistentry><term>Range</term><listitem><para>0 (caching enabled) or 1 (caching disabled)</para>
</listitem>
</varlistentry><varlistentry><term>Units</term><listitem><para>Boolean values</para>
</listitem>
</varlistentry><varlistentry><term>Dynamic?</term><listitem><para>Yes</para>
</listitem>
</varlistentry><varlistentry><term>Validation</term><listitem><para>None</para>
</listitem>
</varlistentry><varlistentry><term>When to Change</term><listitem><para>The <literal>pathconf</literal> information is cached on a
per file basis. However, if the server can change the information for a specific
file dynamically, use this parameter to disable caching. There is no mechanism
for the client to validate its cache entry.</para>
</listitem>
</varlistentry><varlistentry><term>Commitment Level</term><listitem><para>Unstable</para>
</listitem>
</varlistentry>
</variablelist>
</sect2><sect2 id="chapter3-32"><title><literal>nfs:nfs4_pathconf_disable_cache</literal></title><variablelist><varlistentry><term>Description</term><listitem><para>Controls the caching of <literal>pathconf</literal> information
for NFS Version 4 mounted file systems.</para>
</listitem>
</varlistentry><varlistentry><term>Data Type</term><listitem><para>Integer (32-bit)</para>
</listitem>
</varlistentry><varlistentry><term>Default</term><listitem><para>0 (caching enabled)</para>
</listitem>
</varlistentry><varlistentry><term>Range</term><listitem><para>0 (caching enabled) or 1 (caching disabled)</para>
</listitem>
</varlistentry><varlistentry><term>Units</term><listitem><para>Boolean values</para>
</listitem>
</varlistentry><varlistentry><term>Dynamic?</term><listitem><para>Yes</para>
</listitem>
</varlistentry><varlistentry><term>Validation</term><listitem><para>None</para>
</listitem>
</varlistentry><varlistentry><term>When to Change</term><listitem><para>The <literal>pathconf</literal> information is cached on a
per file basis. However, if the server can change the information for a specific
file dynamically, use this parameter to disable caching. There is no mechanism
for the client to validate its cache entry.</para>
</listitem>
</varlistentry><varlistentry><term>Commitment Level</term><listitem><para>Unstable</para>
</listitem>
</varlistentry>
</variablelist>
</sect2><sect2 id="chapter3-31"><title><literal>nfs:nfs_allow_preepoch_time</literal></title><variablelist><varlistentry><term>Description</term><listitem><para>Controls whether files with incorrect or <emphasis>negative</emphasis> time
stamps should be made visible on the client.</para><para>Historically, neither the NFS client nor the NFS server would do any
range checking on the file times being returned. The over-the-wire timestamp
values are unsigned and 32-bits long. So, all values have been legal.</para><para>However, on a system running a 32-bit Solaris kernel, the timestamp
values are signed and 32-bits long. Thus, it would be possible to have a timestamp
representation that appeared to be prior to January 1, 1970, or <emphasis>pre-epoch</emphasis>.</para><para>The problem on a system running a 64-bit Solaris kernel is slightly
different. The timestamp values on the 64-bit Solaris kernel are signed and
64-bits long. It is impossible to determine whether a time field represents
a full 32-bit time or a negative time, that is, a time prior to January 1,
1970.</para><para>It is impossible to determine whether to sign extend a time value
when converting from 32 bits to 64 bits. The time value should be sign extended
if the time value is truly a negative number. However, the time value should
not be sign extended if it does truly represent a full 32-bit time value.
This problem is resolved by simply disallowing full 32-bit time values.</para>
</listitem>
</varlistentry><varlistentry><term>Data Type</term><listitem><para>Integer (32-bit)</para>
</listitem>
</varlistentry><varlistentry><term>Default</term><listitem><para>0 (32-bit time stamps disabled)</para>
</listitem>
</varlistentry><varlistentry><term>Range</term><listitem><para>0 (32-bit time stamps disabled) or 1 (32-bit time stamps enabled)</para>
</listitem>
</varlistentry><varlistentry><term>Units</term><listitem><para>Boolean values</para>
</listitem>
</varlistentry><varlistentry><term>Dynamic?</term><listitem><para>Yes</para>
</listitem>
</varlistentry><varlistentry><term>Validation</term><listitem><para>None</para>
</listitem>
</varlistentry><varlistentry><term>When to Change</term><listitem><para>Even during normal operation, it is possible for the timestamp
values on some files to be set very far in the future or very far in the past.
If access to these files is preferred using NFS mounted file systems, set
this parameter to 1 to allow the timestamp values to be passed through unchecked.</para>
</listitem>
</varlistentry><varlistentry><term>Commitment Level</term><listitem><para>Unstable</para>
</listitem>
</varlistentry>
</variablelist>
</sect2><sect2 id="chapter3-4"><title><literal>nfs:nfs_cots_timeo</literal></title><variablelist><varlistentry><term>Description</term><listitem><para>Controls the default RPC timeout for NFS version 2 mounted file
systems using connection-oriented transports such as TCP for the transport
protocol. </para>
</listitem>
</varlistentry><varlistentry><term>Data Type</term><listitem><para>Signed integer (32-bit)</para>
</listitem>
</varlistentry><varlistentry><term>Default</term><listitem><para>600 (60 seconds)</para>
</listitem>
</varlistentry><varlistentry><term>Range</term><listitem><para>0 to 2<superscript>31</superscript> - 1</para>
</listitem>
</varlistentry><varlistentry><term>Units</term><listitem><para>10th of seconds</para>
</listitem>
</varlistentry><varlistentry><term>Dynamic?</term><listitem><para>Yes, but the RPC timeout for a file system is set when the
file system is mounted. To affect a particular file system, unmount and mount
the file system after changing this parameter.</para>
</listitem>
</varlistentry><varlistentry><term>Validation</term><listitem><para>None</para>
</listitem>
</varlistentry><varlistentry><term>When to Change</term><listitem><para>TCP does a good job ensuring requests and responses are delivered
appropriately. However, if the round-trip times are very large in a particularly
slow network, the NFS version 2 client might time out prematurely.</para><para>Increase this parameter to prevent the client from timing out incorrectly.
The range of values is very large, so increasing this value too much might
result in situations where a retransmission is not detected for long periods
of time.</para>
</listitem>
</varlistentry><varlistentry><term>Commitment Level</term><listitem><para>Unstable</para>
</listitem>
</varlistentry>
</variablelist>
</sect2><sect2 id="chapter3-5"><title><literal>nfs:nfs3_cots_timeo</literal></title><variablelist><varlistentry><term>Description</term><listitem><para>Controls the default RPC timeout for NFS version 3 mounted file
systems using connection-oriented transports such as TCP for the transport
protocol.  </para>
</listitem>
</varlistentry><varlistentry><term>Data Type</term><listitem><para>Signed integer (32-bit)</para>
</listitem>
</varlistentry><varlistentry><term>Default</term><listitem><para>600 (60 seconds)</para>
</listitem>
</varlistentry><varlistentry><term>Range</term><listitem><para>0 to 2<superscript>31</superscript> - 1</para>
</listitem>
</varlistentry><varlistentry><term>Units</term><listitem><para>10th of seconds</para>
</listitem>
</varlistentry><varlistentry><term>Dynamic?</term><listitem><para>Yes, but the RPC timeout for a file system is set when the
file system is mounted. To affect a particular file system, unmount and mount
the file system after changing this parameter.</para>
</listitem>
</varlistentry><varlistentry><term>Validation</term><listitem><para>None</para>
</listitem>
</varlistentry><varlistentry><term>When to Change</term><listitem><para>TCP does a good job ensuring requests and responses are delivered
appropriately. However, if the round-trip times are very large in a particularly
slow network, the NFS version 3 client might time out prematurely.</para><para>Increase this parameter to prevent the client from timing out incorrectly.
The range of values is very large, so increasing this value too much might
result in situations where a retransmission is not detected for long periods
of time.</para>
</listitem>
</varlistentry><varlistentry><term>Commitment Level</term><listitem><para>Unstable</para>
</listitem>
</varlistentry>
</variablelist>
</sect2><sect2 id="chapter3-50"><title><literal>nfs:nfs4_cots_timeo</literal></title><variablelist><varlistentry><term>Description</term><listitem><para>Controls the default RPC timeout for NFS version 4 mounted file
systems using connection-oriented transports such as TCP for the transport
protocol.  </para><para>The NFS Version 4 protocol specification disallows retransmission over
the same TCP connection. Thus, this parameter primarily controls how quickly
the client responds to certain events, such as detecting a forced unmount
operation or detecting how quickly the server fails over to a new server.</para>
</listitem>
</varlistentry><varlistentry><term>Data Type</term><listitem><para>Signed integer (32-bit)</para>
</listitem>
</varlistentry><varlistentry><term>Default</term><listitem><para>600 (60 seconds)</para>
</listitem>
</varlistentry><varlistentry><term>Range</term><listitem><para>0 to 2<superscript>31</superscript> - 1</para>
</listitem>
</varlistentry><varlistentry><term>Units</term><listitem><para>10th of seconds</para>
</listitem>
</varlistentry><varlistentry><term>Dynamic?</term><listitem><para>Yes, but this parameter is set when the file system is mounted.
To affect a particular file system, unmount and mount the file system after
changing this parameter.</para>
</listitem>
</varlistentry><varlistentry><term>Validation</term><listitem><para>None</para>
</listitem>
</varlistentry><varlistentry><term>When to Change</term><listitem><para>TCP does a good job ensuring requests and responses are delivered
appropriately. However, if the round-trip times are very large in a particularly
slow network, the NFS version 4 client might time out prematurely.</para><para>Increase this parameter to prevent the client from timing out incorrectly.
The range of values is very large, so increasing this value too much might
result in situations where a retransmission is not detected for long periods
of time.</para>
</listitem>
</varlistentry><varlistentry><term>Commitment Level</term><listitem><para>Unstable</para>
</listitem>
</varlistentry>
</variablelist>
</sect2><sect2 id="chapter3-6"><title><literal>nfs:nfs_do_symlink_cache</literal></title><variablelist><varlistentry><term>Description</term><listitem><para>Controls whether the contents of symbolic link files are cached
for NFS version 2 mounted file systems.</para>
</listitem>
</varlistentry><varlistentry><term>Data Type</term><listitem><para>Integer (32&ndash;bit)</para>
</listitem>
</varlistentry><varlistentry><term>Default</term><listitem><para>1 (caching enabled)</para>
</listitem>
</varlistentry><varlistentry><term>Range</term><listitem><para>0 (caching disabled) or 1 (caching enabled)</para>
</listitem>
</varlistentry><varlistentry><term>Units</term><listitem><para>Boolean values</para>
</listitem>
</varlistentry><varlistentry><term>Dynamic?</term><listitem><para>Yes</para>
</listitem>
</varlistentry><varlistentry><term>Validation</term><listitem><para>None</para>
</listitem>
</varlistentry><varlistentry><term>When to Change</term><listitem><para>If a server changes the contents of a symbolic link file without
updating the modification timestamp on the file or if the granularity of the
timestamp is too large, then changes to the contents of the symbolic link
file might not be visible on the client for extended periods. In this case,
use this parameter to disable the caching of symbolic link contents. Doing
so makes the changes immediately visible to applications running on the client.</para>
</listitem>
</varlistentry><varlistentry><term>Commitment Level</term><listitem><para>Unstable</para>
</listitem>
</varlistentry>
</variablelist>
</sect2><sect2 id="chapter3-7"><title><literal>nfs:nfs3_do_symlink_cache</literal></title><variablelist><varlistentry><term>Description</term><listitem><para>Controls whether the contents of symbolic link files are cached
for NFS version 3 mounted file systems.</para>
</listitem>
</varlistentry><varlistentry><term>Data Type</term><listitem><para>Integer (32-bit)</para>
</listitem>
</varlistentry><varlistentry><term>Default</term><listitem><para>1 (caching enabled)</para>
</listitem>
</varlistentry><varlistentry><term>Range</term><listitem><para>0 (caching disabled) or 1 (caching enabled)</para>
</listitem>
</varlistentry><varlistentry><term>Units</term><listitem><para>Boolean values</para>
</listitem>
</varlistentry><varlistentry><term>Dynamic?</term><listitem><para>Yes</para>
</listitem>
</varlistentry><varlistentry><term>Validation</term><listitem><para>None</para>
</listitem>
</varlistentry><varlistentry><term>When to Change</term><listitem><para>If a server changes the contents of a symbolic link file without
updating the modification timestamp on the file or if the granularity of the
timestamp is too large, then changes to the contents of the symbolic link
file might not be visible on the client for extended periods.  In this case,
use this parameter to disable the caching of symbolic link contents. Doing
so makes the changes immediately visible to applications running on the client.</para>
</listitem>
</varlistentry><varlistentry><term>Commitment Level</term><listitem><para>Unstable</para>
</listitem>
</varlistentry>
</variablelist>
</sect2><sect2 id="chapter3-28"><title><literal>nfs:nfs4_do_symlink_cache</literal></title><variablelist><varlistentry><term>Description</term><listitem><para>Controls whether the contents of symbolic link files are cached
for NFS version 4 mounted file systems.</para>
</listitem>
</varlistentry><varlistentry><term>Data Type</term><listitem><para>Integer (32-bit)</para>
</listitem>
</varlistentry><varlistentry><term>Default</term><listitem><para>1 (caching enabled)</para>
</listitem>
</varlistentry><varlistentry><term>Range</term><listitem><para>0 (caching disabled) or 1 (caching enabled)</para>
</listitem>
</varlistentry><varlistentry><term>Units</term><listitem><para>Boolean values</para>
</listitem>
</varlistentry><varlistentry><term>Dynamic?</term><listitem><para>Yes</para>
</listitem>
</varlistentry><varlistentry><term>Validation</term><listitem><para>None</para>
</listitem>
</varlistentry><varlistentry><term>When to Change</term><listitem><para>If a server changes the contents of a symbolic link file without
updating the modification timestamp on the file or if the granularity of the
timestamp is too large, then changes to the contents of the symbolic link
file might not be visible on the client for extended periods. In this case,
use this parameter to disable the caching of symbolic link contents. Doing
so makes the changes immediately visible to applications running on the client.</para>
</listitem>
</varlistentry><varlistentry><term>Commitment Level</term><listitem><para>Unstable</para>
</listitem>
</varlistentry>
</variablelist>
</sect2><sect2 id="chapter3-8"><title><literal>nfs:nfs_dynamic</literal></title><variablelist><varlistentry><term>Description</term><listitem><para>Controls whether a feature known as <emphasis>dynamic retransmission</emphasis> is
enabled for NFS version 2 mounted file systems using connectionless transports
such as UDP. This feature attempts to reduce retransmissions by monitoring
server response times and then adjusting RPC timeouts and read- and write-
transfer sizes.</para>
</listitem>
</varlistentry><varlistentry><term>Data Type</term><listitem><para>Integer (32-bit)</para>
</listitem>
</varlistentry><varlistentry><term>Default</term><listitem><para>1 (enabled)</para>
</listitem>
</varlistentry><varlistentry><term>Range</term><listitem><para>0 (disabled) or 1 (enabled)</para>
</listitem>
</varlistentry><varlistentry><term>Dynamic?</term><listitem><para>Yes, but this parameter is set per file system at mount time.
To affect a particular file system, unmount and mount the file system after
changing this parameter.</para>
</listitem>
</varlistentry><varlistentry><term>Validation</term><listitem><para>None</para>
</listitem>
</varlistentry><varlistentry><term>When to Change</term><listitem><para>Do not change this parameter.</para>
</listitem>
</varlistentry><varlistentry><term>Commitment Level</term><listitem><para>Unstable</para>
</listitem>
</varlistentry>
</variablelist>
</sect2><sect2 id="chapter3-9"><title><literal>nfs:nfs3_dynamic</literal></title><variablelist><varlistentry><term>Description</term><listitem><para>Controls whether a feature known as <emphasis>dynamic retransmission</emphasis> is
enabled for NFS version 3 mounted file systems using connectionless transports
such as UDP. This feature attempts to reduce retransmissions by monitoring
server response times and then adjusting RPC timeouts and read- and write-
transfer sizes.</para>
</listitem>
</varlistentry><varlistentry><term>Data Type</term><listitem><para>Integer (32-bit)</para>
</listitem>
</varlistentry><varlistentry><term>Default</term><listitem><para>0 (disabled)</para>
</listitem>
</varlistentry><varlistentry><term>Range</term><listitem><para>0 (disabled) or 1 (enabled)</para>
</listitem>
</varlistentry><varlistentry><term>Units</term><listitem><para>Boolean values</para>
</listitem>
</varlistentry><varlistentry><term>Dynamic?</term><listitem><para>Yes, but this parameter is set per file system at mount time.
To affect a particular file system, unmount and mount the file system after
changing this parameter.</para>
</listitem>
</varlistentry><varlistentry><term>Validation</term><listitem><para>None</para>
</listitem>
</varlistentry><varlistentry><term>When to Change</term><listitem><para>Do not change this parameter.</para>
</listitem>
</varlistentry><varlistentry><term>Commitment Level</term><listitem><para>Unstable</para>
</listitem>
</varlistentry>
</variablelist>
</sect2><sect2 id="chapter3-10"><title><literal>nfs:nfs_lookup_neg_cache</literal></title><variablelist><varlistentry><term>Description</term><listitem><para>Controls whether a negative name cache is used for NFS version
2 mounted file systems. This negative name cache records file names that were
looked up, but not found. The cache is used to avoid over-the-network look-up
requests made for file names that are already known to not exist.</para>
</listitem>
</varlistentry><varlistentry><term>Data Type</term><listitem><para>Integer (32-bit)</para>
</listitem>
</varlistentry><varlistentry><term>Default</term><listitem><para>1 (enabled)</para>
</listitem>
</varlistentry><varlistentry><term>Range</term><listitem><para>0 (disabled) or 1 (enabled)</para>
</listitem>
</varlistentry><varlistentry><term>Units</term><listitem><para>Boolean values</para>
</listitem>
</varlistentry><varlistentry><term>Dynamic?</term><listitem><para>Yes</para>
</listitem>
</varlistentry><varlistentry><term>Validation</term><listitem><para>None</para>
</listitem>
</varlistentry><varlistentry><term>When to Change</term><listitem><para>For the cache to perform correctly, negative entries must
be strictly verified before they are used. This consistency mechanism is relaxed
slightly for read-only mounted file systems. It is assumed that the file system
on the server is not changing or is changing very slowly, and that it is okay
for such changes to propagate slowly to the client. The consistency mechanism
becomes the normal attribute cache mechanism in this case.</para><para>If file systems are mounted read-only on the client, but are expected
to change on the server and these changes need to be seen immediately by the
client, use this parameter to disable the negative cache.</para><para>If you disable the <literal>nfs:nfs_disable_rddir_cache</literal> parameter,
you should probably also disable this parameter. For more information, see <olink targetptr="chapter3-36" remap="internal">nfs:nfs_disable_rddir_cache</olink>.</para>
</listitem>
</varlistentry><varlistentry><term>Commitment Level</term><listitem><para>Unstable</para>
</listitem>
</varlistentry>
</variablelist>
</sect2><sect2 id="chapter3-11"><title><literal>nfs:nfs3_lookup_neg_cache</literal></title><variablelist><varlistentry><term>Description</term><listitem><para>Controls whether a negative name cache is used for NFS version
3 mounted file systems. This negative name cache records file names that were
looked up, but were not found. The cache is used to avoid over-the-network
look-up requests made for file names that are already known to not exist.</para>
</listitem>
</varlistentry><varlistentry><term>Data Type</term><listitem><para>Integer (32-bit)</para>
</listitem>
</varlistentry><varlistentry><term>Default</term><listitem><para>1 (enabled)</para>
</listitem>
</varlistentry><varlistentry><term>Range</term><listitem><para>0 (disabled) or 1 (enabled)</para>
</listitem>
</varlistentry><varlistentry><term>Units</term><listitem><para>Boolean values</para>
</listitem>
</varlistentry><varlistentry><term>Dynamic?</term><listitem><para>Yes</para>
</listitem>
</varlistentry><varlistentry><term>Validation</term><listitem><para>None</para>
</listitem>
</varlistentry><varlistentry><term>When to Change</term><listitem><para>For the cache to perform correctly, negative entries must
be strictly verified before they are used. This consistency mechanism is relaxed
slightly for read-only mounted file systems. It is assumed that the file system
on the server is not changing or is changing very slowly, and that it is okay
for such changes to propagate slowly to the client. The consistency mechanism
becomes the normal attribute cache mechanism in this case. </para><para>If file systems are mounted read-only on the client, but are expected
to change on the server and these changes need to be seen immediately by the
client, use this parameter to disable the negative cache.</para><para>If you disable the <literal>nfs:nfs_disable_rddir_cache</literal> parameter,
you should probably also disable this parameter. For more information, see <olink targetptr="chapter3-36" remap="internal">nfs:nfs_disable_rddir_cache</olink>.</para>
</listitem>
</varlistentry><varlistentry><term>Commitment Level</term><listitem><para>Unstable</para>
</listitem>
</varlistentry>
</variablelist>
</sect2><sect2 id="chapter3-29"><title><literal>nfs:nfs4_lookup_neg_cache</literal></title><variablelist><varlistentry><term>Description</term><listitem><para>Controls whether a negative name cache is used for NFS version
4 mounted file systems. This negative name cache records file names that were
looked up, but were not found. The cache is used to avoid over-the-network
look-up requests made for file names that are already known to not exist.</para>
</listitem>
</varlistentry><varlistentry><term>Data Type</term><listitem><para>Integer (32-bit)</para>
</listitem>
</varlistentry><varlistentry><term>Default</term><listitem><para>1 (enabled)</para>
</listitem>
</varlistentry><varlistentry><term>Range</term><listitem><para>0 (disabled) or 1 (enabled)</para>
</listitem>
</varlistentry><varlistentry><term>Units</term><listitem><para>Boolean values</para>
</listitem>
</varlistentry><varlistentry><term>Dynamic?</term><listitem><para>Yes</para>
</listitem>
</varlistentry><varlistentry><term>Validation</term><listitem><para>None</para>
</listitem>
</varlistentry><varlistentry><term>When to Change</term><listitem><para>For the cache to perform correctly, negative entries must
be strictly verified before they are used. This consistency mechanism is relaxed
slightly for read-only mounted file systems. It is assumed that the file system
on the server is not changing or is changing very slowly, and that it is okay
for such changes to propagate slowly to the client. The consistency mechanism
becomes the normal attribute cache mechanism in this case. </para><para>If file systems are mounted read-only on the client, but are expected
to change on the server and these changes need to be seen immediately by the
client, use this parameter to disable the negative cache.</para><para>If you disable the <literal>nfs:nfs_disable_rddir_cache</literal> parameter,
you should probably also disable this parameter. For more information, see <olink targetptr="chapter3-36" remap="internal">nfs:nfs_disable_rddir_cache</olink>.</para>
</listitem>
</varlistentry><varlistentry><term>Commitment Level</term><listitem><para>Unstable</para>
</listitem>
</varlistentry>
</variablelist>
</sect2><sect2 id="chapter3-12"><title><literal>nfs:nfs_max_threads</literal></title><variablelist><varlistentry><term>Description</term><listitem><para>Controls the number of kernel threads that perform asynchronous
I/O for the NFS version 2 client. Because NFS is based on RPC and RPC is inherently
synchronous, separate execution contexts are required to perform NFS operations
that are asynchronous from the calling thread.</para><para>The operations that can be executed asynchronously are read for
read-ahead, readdir for readdir read-ahead, write for putpage and pageio operations,
commit, and inactive for cleanup operations that the client performs when
it stops using a file.</para>
</listitem>
</varlistentry><varlistentry><term>Data Type</term><listitem><para>Integer (16-bit)</para>
</listitem>
</varlistentry><varlistentry><term>Default</term><listitem><para>8</para>
</listitem>
</varlistentry><varlistentry><term>Range</term><listitem><para>0 to 2<superscript>15</superscript> - 1</para>
</listitem>
</varlistentry><varlistentry><term>Units</term><listitem><para>Threads</para>
</listitem>
</varlistentry><varlistentry><term>Dynamic?</term><listitem><para>Yes, but this parameter is set per file system at mount time.
To affect a particular file system, unmount and mount the file system after
changing this parameter.</para>
</listitem>
</varlistentry><varlistentry><term>Validation</term><listitem><para>None</para>
</listitem>
</varlistentry><varlistentry><term>When to Change</term><listitem><para>To increase or reduce the number of simultaneous I/O operations
that are outstanding at any given time. For example, for a very low bandwidth
network, you might want to decrease this value so that the NFS client does
not overload the network. Alternately, if the network is very high bandwidth,
and the client and server have sufficient resources, you might want to increase
this value. Doing so can more effectively utilize the available network bandwidth,
and the client and server resources.</para>
</listitem>
</varlistentry><varlistentry><term>Commitment Level</term><listitem><para>Unstable</para>
</listitem>
</varlistentry>
</variablelist>
</sect2><sect2 id="chapter3-13"><title><literal>nfs:nfs3_max_threads</literal></title><variablelist><varlistentry><term>Description</term><listitem><para>Controls the number of kernel threads that perform asynchronous
I/O for the NFS version 3 client. Because NFS is based on RPC and RPC is inherently
synchronous, separate execution contexts are required to perform NFS operations
that are asynchronous from the calling thread.</para><para>The operations that can be executed asynchronously are read for
read-ahead, readdir for readdir read-ahead, write for putpage and pageio requests,
and commit.</para>
</listitem>
</varlistentry><varlistentry><term>Data Type</term><listitem><para>Integer (16-bit)</para>
</listitem>
</varlistentry><varlistentry><term>Default</term><listitem><para>8</para>
</listitem>
</varlistentry><varlistentry><term>Range</term><listitem><para>0 to 2<superscript>15</superscript> - 1</para>
</listitem>
</varlistentry><varlistentry><term>Units</term><listitem><para>Threads</para>
</listitem>
</varlistentry><varlistentry><term>Dynamic?</term><listitem><para>Yes, but this parameter is set per file system at mount time.
To affect a particular file system, unmount and mount the file system after
changing this parameter.</para>
</listitem>
</varlistentry><varlistentry><term>Validation</term><listitem><para>None</para>
</listitem>
</varlistentry><varlistentry><term>When to Change</term><listitem><para>To increase or reduce the number of simultaneous I/O operations
that are outstanding at any given time. For example, for a very low bandwidth
network, you might want to decrease this value so that the NFS client does
not overload the network. Alternately, if the network is very high bandwidth,
and the client and server have sufficient resources, you might want to increase
this value. Doing so can more effectively utilize the available network bandwidth,
and the client and server resources.</para>
</listitem>
</varlistentry><varlistentry><term>Commitment Level</term><listitem><para>Unstable</para>
</listitem>
</varlistentry>
</variablelist>
</sect2><sect2 id="chapter3-33"><title><literal>nfs:nfs4_max_threads</literal></title><variablelist><varlistentry><term>Description</term><listitem><para>Controls the number of kernel threads that perform asynchronous
I/O for the NFS version 4 client. Because NFS is based on RPC and RPC is inherently
synchronous, separate execution contexts are required to perform NFS operations
that are asynchronous from the calling thread.</para><para>The operations that can be executed asynchronously are read for
read-ahead, write-behind, directory read-ahead, and cleanup operations that
the client performs when it stops using a file.</para>
</listitem>
</varlistentry><varlistentry><term>Data Type</term><listitem><para>Integer (16-bit)</para>
</listitem>
</varlistentry><varlistentry><term>Default</term><listitem><para>8</para>
</listitem>
</varlistentry><varlistentry><term>Range</term><listitem><para>0 to 2<superscript>15</superscript> - 1</para>
</listitem>
</varlistentry><varlistentry><term>Units</term><listitem><para>Threads</para>
</listitem>
</varlistentry><varlistentry><term>Dynamic?</term><listitem><para>Yes, but this parameter is set per file system at mount time.
To affect a particular file system, unmount and mount the file system after
changing this parameter.</para>
</listitem>
</varlistentry><varlistentry><term>Validation</term><listitem><para>None</para>
</listitem>
</varlistentry><varlistentry><term>When to Change</term><listitem><para>To increase or reduce the number of simultaneous I/O operations
that are outstanding at any given time. For example, for a very low bandwidth
network, you might want to decrease this value so that the NFS client does
not overload the network. Alternately, if the network is very high bandwidth,
and the client and server have sufficient resources, you might want to increase
this value. Doing so can more effectively utilize the available network bandwidth,
and the client and server resources.</para>
</listitem>
</varlistentry><varlistentry><term>Commitment Level</term><listitem><para>Unstable</para>
</listitem>
</varlistentry>
</variablelist>
</sect2><sect2 id="chapter3-15"><title><literal>nfs:nfs_nra</literal></title><variablelist><varlistentry><term>Description</term><listitem><para>Controls the number of read-ahead operations that are queued by
the NFS version 2 client when sequential access to a file is discovered. These
read-ahead operations increase concurrency and read throughput.  Each read-ahead
request is generally for one logical block of file data.</para>
</listitem>
</varlistentry><varlistentry><term>Data Type</term><listitem><para>Integer (32-bit)</para>
</listitem>
</varlistentry><varlistentry><term>Default</term><listitem><para>4</para>
</listitem>
</varlistentry><varlistentry><term>Range</term><listitem><para>0 to 2<superscript>31</superscript> - 1</para>
</listitem>
</varlistentry><varlistentry><term>Units</term><listitem><para>Logical blocks. (See <olink targetptr="chapter3-57" remap="internal">nfs:nfs_bsize</olink>.)</para>
</listitem>
</varlistentry><varlistentry><term>Dynamic?</term><listitem><para>Yes</para>
</listitem>
</varlistentry><varlistentry><term>Validation</term><listitem><para>None</para>
</listitem>
</varlistentry><varlistentry><term>When to Change</term><listitem><para>To increase or reduce the number of read-ahead requests that
are outstanding for a specific file at any given time. For example, for a
very low bandwidth network or on a low memory client, you might want to decrease
this value so that the NFS client does not overload the network or the system
memory. Alternately, if the network is very high bandwidth, and the client
and server have sufficient resources, you might want to increase this value.
Doing so can more effectively utilize the available network bandwidth, and
the client and server resources.</para>
</listitem>
</varlistentry><varlistentry><term>Commitment Level</term><listitem><para>Unstable</para>
</listitem>
</varlistentry>
</variablelist>
</sect2><sect2 id="chapter3-16"><title><literal>nfs:nfs3_nra</literal></title><variablelist><varlistentry><term>Description</term><listitem><para>Controls the number of read-ahead operations that are queued by
the NFS version 3 client when sequential access to a file is discovered. These
read-ahead operations increase concurrency and read throughput. Each read-ahead
request is generally for one logical block of file data.</para>
</listitem>
</varlistentry><varlistentry><term>Data Type</term><listitem><para>Integer (32-bit)</para>
</listitem>
</varlistentry><varlistentry><term>Default</term><listitem><para>4</para>
</listitem>
</varlistentry><varlistentry><term>Range</term><listitem><para>0 to 2<superscript>31</superscript> - 1</para>
</listitem>
</varlistentry><varlistentry><term>Units</term><listitem><para>Logical blocks. (See <olink targetptr="chapter3-35" remap="internal">nfs:nfs3_bsize</olink>.)</para>
</listitem>
</varlistentry><varlistentry><term>Dynamic?</term><listitem><para>Yes</para>
</listitem>
</varlistentry><varlistentry><term>Validation</term><listitem><para>None</para>
</listitem>
</varlistentry><varlistentry><term>When to Change</term><listitem><para>To increase or reduce the number of read-ahead requests that
are outstanding for a specific file at any given time. For example, for a
very low bandwidth network or on a low memory client, you might want to decrease
this value so that the NFS client does not overload the network or the system
memory. Alternately, if the network is very high bandwidth and the client
and server have sufficient resources, you might want to increase this value.
Doing so can more effectively utilize the available network bandwidth, and
the client and server resources.</para>
</listitem>
</varlistentry><varlistentry><term>Commitment Level</term><listitem><para>Unstable</para>
</listitem>
</varlistentry><varlistentry><term>Change History</term><listitem><para>For information, see <olink targetptr="gdoef" remap="internal">nfs:nfs3_nra
(Solaris 10)</olink>.</para>
</listitem>
</varlistentry>
</variablelist>
</sect2><sect2 id="chapter3-14"><title><literal>nfs:nfs4_nra</literal></title><variablelist><varlistentry><term>Description</term><listitem><para>Controls the number of read-ahead operations that are queued by
the NFS version 4 client when sequential access to a file is discovered. These
read-ahead operations increase concurrency and read throughput. Each read-ahead
request is generally for one logical block of file data.</para>
</listitem>
</varlistentry><varlistentry><term>Data Type</term><listitem><para>Integer (32-bit)</para>
</listitem>
</varlistentry><varlistentry><term>Default</term><listitem><para>4</para>
</listitem>
</varlistentry><varlistentry><term>Range</term><listitem><para>0 to 2<superscript>31</superscript> - 1</para>
</listitem>
</varlistentry><varlistentry><term>Units</term><listitem><para>Logical blocks. (See <olink targetptr="chapter3-37" remap="internal">nfs:nfs4_bsize</olink>.)</para>
</listitem>
</varlistentry><varlistentry><term>Dynamic?</term><listitem><para>Yes</para>
</listitem>
</varlistentry><varlistentry><term>Validation</term><listitem><para>None</para>
</listitem>
</varlistentry><varlistentry><term>When to Change</term><listitem><para>To increase or reduce the number of read-ahead requests that
are outstanding for a specific file at any given time. For example, for a
very low bandwidth network or on a low memory client, you might want to decrease
this value so that the NFS client does not overload the network or the system
memory. Alternately, if the network is very high bandwidth, and the client
and server have sufficient resources, you might want to increase this value.
Doing so can more effectively utilize the available network bandwidth, and
the client and server resources.</para>
</listitem>
</varlistentry><varlistentry><term>Commitment Level</term><listitem><para>Unstable</para>
</listitem>
</varlistentry>
</variablelist>
</sect2><sect2 id="chapter3-17"><title><literal>nfs:nrnode</literal></title><variablelist><varlistentry><term>Description</term><listitem><para>Controls the size of the <literal>rnode</literal> cache on
the NFS client.</para><para>The <literal>rnode</literal>, used by both NFS
version 2, 3, and 4 clients, is the central data structure that describes
a file on the NFS client. The <literal>rnode</literal> contains the file handle
that identifies the file on the server. The <literal>rnode</literal> also
contains pointers to various caches used by the NFS client to avoid network
calls to the server.  Each <literal>rnode</literal> has a one-to-one association
with a <literal>vnode</literal>. The <literal>vnode</literal> caches file
data.</para><para>The
NFS client attempts to maintain a minimum number of <literal>rnode</literal>s
to attempt to avoid destroying cached data and metadata. When an <literal>rnode</literal> is
reused or freed, the cached data and metadata must be destroyed.</para>
</listitem>
</varlistentry><varlistentry><term>Data Type</term><listitem><para>Integer (32-bit)</para>
</listitem>
</varlistentry><varlistentry><term>Default</term><listitem><para>The default setting of this parameter is 0, which means that
the value of <literal>nrnode</literal> should be set to the value of the <literal>ncsize</literal> parameter. Actually, any non positive value of <literal>nrnode</literal> results
in <literal>nrnode</literal> being set to the value of <literal>ncsize</literal>.</para>
</listitem>
</varlistentry><varlistentry><term>Range</term><listitem><para>1 to 2<superscript>31</superscript> - 1</para>
</listitem>
</varlistentry><varlistentry><term>Units</term><listitem><para><literal>rnode</literal>s</para>
</listitem>
</varlistentry><varlistentry><term>Dynamic?</term><listitem><para>No. This value can only be changed by adding or changing the
parameter in the <filename>/etc/system</filename> file, and then rebooting
the system.</para>
</listitem>
</varlistentry><varlistentry><term>Validation</term><listitem><para>The system enforces a maximum value such that the <literal>rnode</literal> cache
can only consume 25 percent of available memory.</para>
</listitem>
</varlistentry><varlistentry><term>When to Change</term><listitem><para>Because <literal>rnode</literal>s are created and destroyed
dynamically, the system tends to settle upon a <replaceable>nrnode</replaceable>-size
cache, automatically adjusting the size of the cache as memory pressure on
the system increases or as more files are simultaneously accessed.  However,
in certain situations, you could set the value of <literal>nrnode</literal> if
the mix of files being accessed can be predicted in advance. For example,
if the NFS client is accessing a few very large files, you could set the value
of <literal>nrnode</literal> to a small number so that system memory can cache
file data instead of <literal>rnode</literal>s. Alternately, if the client
is accessing many small files, you could increase the value of <literal>nrnode</literal> to
optimize for storing file metadata to reduce the number of network calls for
metadata.</para><para>Although it is not recommended, the <literal>rnode</literal> cache can
be effectively disabled by setting the value of <literal>nrnode</literal> to
1. This value instructs the client to only cache 1 <literal>rnode</literal>,
which means that it is reused frequently.</para>
</listitem>
</varlistentry><varlistentry><term>Commitment Level</term><listitem><para>Unstable</para>
</listitem>
</varlistentry><varlistentry><term>Change History</term><listitem><para>For information, see <olink targetptr="appendixa-48" remap="internal">nfs:nrnode
(Solaris 9 8/03)</olink>.</para>
</listitem>
</varlistentry>
</variablelist>
</sect2><sect2 id="chapter3-18"><title><literal>nfs:nfs_shrinkreaddir</literal></title><variablelist><varlistentry><term>Description</term><listitem><para>Some older NFS servers might incorrectly handle NFS version
2 <literal>READDIR</literal> requests for more than 1024 bytes of directory
information. This problem is due to a bug in the server implementation. However,
this parameter contains a workaround in the NFS version 2 client.</para><para>When this parameter is enabled, the client does not generate a <literal>READDIR</literal> request for larger than 1024 bytes of directory information.
If this parameter is disabled, then the over-the-wire size is set to the lesser
of either the size passed in by using the <literal>getdents</literal> system
call or by using <literal>NFS_MAXDATA</literal>, which is 8192 bytes. For
more information, see <olink targetdoc="refman2" targetptr="getdents-2" remap="external"><citerefentry><refentrytitle>getdents</refentrytitle><manvolnum>2</manvolnum></citerefentry></olink>.</para>
</listitem>
</varlistentry><varlistentry><term>Data Type</term><listitem><para>Integer (32-bit)</para>
</listitem>
</varlistentry><varlistentry><term>Default</term><listitem><para>0 (disabled)</para>
</listitem>
</varlistentry><varlistentry><term>Range</term><listitem><para>0 (disabled) or 1 (enabled)</para>
</listitem>
</varlistentry><varlistentry><term>Units</term><listitem><para>Boolean values</para>
</listitem>
</varlistentry><varlistentry><term>Dynamic?</term><listitem><para>Yes</para>
</listitem>
</varlistentry><varlistentry><term>Validation</term><listitem><para>None</para>
</listitem>
</varlistentry><varlistentry><term>When to Change</term><listitem><para>Examine the value of this parameter if an older NFS version
2 only server is used and interoperability problems occur when the server
tries to read directories. Enabling this parameter might cause a slight decrease
in performance for applications that read directories.</para>
</listitem>
</varlistentry><varlistentry><term>Commitment Level</term><listitem><para>Unstable</para>
</listitem>
</varlistentry>
</variablelist>
</sect2><sect2 id="chapter3-24"><title><literal>nfs:nfs3_shrinkreaddir</literal></title><variablelist><varlistentry><term>Description</term><listitem><para>Some older NFS servers might incorrectly handle NFS version
3 <literal>READDIR</literal> requests for more than 1024 bytes of directory
information. This problem is due to a bug in the server implementation. However,
this parameter contains a workaround in the NFS version 3 client.</para><para>When this parameter is enabled, the client does not generate a <literal>READDIR</literal> request for larger than 1024 bytes of directory information.
If this parameter is disabled, then the over-the-wire size is set to the minimum
of either the size passed in by using the <literal>getdents</literal> system
call or by using <literal>MAXBSIZE</literal>, which is 8192 bytes. For more
information, see <olink targetdoc="refman2" targetptr="getdents-2" remap="external"><citerefentry><refentrytitle>getdents</refentrytitle><manvolnum>2</manvolnum></citerefentry></olink>.</para>
</listitem>
</varlistentry><varlistentry><term>Data Type</term><listitem><para>Integer (32-bit)</para>
</listitem>
</varlistentry><varlistentry><term>Default</term><listitem><para>0 (disabled)</para>
</listitem>
</varlistentry><varlistentry><term>Range</term><listitem><para>0 (disabled) or 1 (enabled)</para>
</listitem>
</varlistentry><varlistentry><term>Units</term><listitem><para>Boolean values</para>
</listitem>
</varlistentry><varlistentry><term>Dynamic?</term><listitem><para>Yes</para>
</listitem>
</varlistentry><varlistentry><term>Validation</term><listitem><para>None</para>
</listitem>
</varlistentry><varlistentry><term>When to Change</term><listitem><para>Examine the value of this parameter if an older NFS version
3 only server is used and interoperability problems occur when the server
tries to read directories. Enabling this parameter might cause a slight decrease
in performance for applications that read directories.</para>
</listitem>
</varlistentry><varlistentry><term>Commitment Level</term><listitem><para>Unstable</para>
</listitem>
</varlistentry>
</variablelist>
</sect2><sect2 id="chapter3-38"><title><literal>nfs:nfs4_shrinkreaddir</literal></title><variablelist><varlistentry><term>Description</term><listitem><para>Some NFS servers might incorrectly handle NFS version 4 <literal>READDIR</literal> requests for more than 1024 bytes of directory information.
This problem is due to a bug in the server implementation. However, this parameter
contains a workaround in the NFS version 4 client.</para><para>When this parameter is enabled, the client does not generate a <literal>READDIR</literal> request for larger than 1024 bytes of directory information.
If this parameter is disabled, then the over-the-wire size is set to the lesser
of either the size passed in by using the <literal>getdents</literal> system
call or by using <literal>MAXBSIZE</literal>, which is 8192 bytes. For more
information, see <olink targetdoc="refman2" targetptr="getdents-2" remap="external"><citerefentry><refentrytitle>getdents</refentrytitle><manvolnum>2</manvolnum></citerefentry></olink>.</para>
</listitem>
</varlistentry><varlistentry><term>Data Type</term><listitem><para>Integer (32-bit)</para>
</listitem>
</varlistentry><varlistentry><term>Default</term><listitem><para>0 (disabled)</para>
</listitem>
</varlistentry><varlistentry><term>Range</term><listitem><para>0 (disabled) or 1 (enabled)</para>
</listitem>
</varlistentry><varlistentry><term>Units</term><listitem><para>Boolean values</para>
</listitem>
</varlistentry><varlistentry><term>Dynamic?</term><listitem><para>Yes</para>
</listitem>
</varlistentry><varlistentry><term>Validation</term><listitem><para>None</para>
</listitem>
</varlistentry><varlistentry><term>When to Change</term><listitem><para>Examine the value of this parameter if an NFS version 4 only
server is used and interoperability problems occur when the server tries to
read directories. Enabling this parameter might cause a slight performance
drop for applications that read directories.</para>
</listitem>
</varlistentry><varlistentry><term>Commitment Level</term><listitem><para>Unstable</para>
</listitem>
</varlistentry>
</variablelist>
</sect2><sect2 id="chapter3-19"><title><literal>nfs:nfs_write_error_interval</literal></title><variablelist><varlistentry><term>Description</term><listitem><para>Controls the time duration in between logging <literal>ENOSPC</literal> and <literal>EDQUOT</literal> write errors received by the NFS client. This parameter affects
NFS version 2, 3, and 4 clients.</para>
</listitem>
</varlistentry><varlistentry><term>Data Type</term><listitem><para>Long integer (32 bits on 32-bit platforms and 64 bits  on
64-bit platforms)</para>
</listitem>
</varlistentry><varlistentry><term>Default</term><listitem><para>5 seconds</para>
</listitem>
</varlistentry><varlistentry><term>Range</term><listitem><para>0 to 2<superscript>31</superscript> - 1 on 32-bit platforms</para><para>0 to 2<superscript>63</superscript> - 1 on 64-bit platforms</para>
</listitem>
</varlistentry><varlistentry><term>Units</term><listitem><para>Seconds</para>
</listitem>
</varlistentry><varlistentry><term>Dynamic?</term><listitem><para>Yes</para>
</listitem>
</varlistentry><varlistentry><term>Validation</term><listitem><para>None</para>
</listitem>
</varlistentry><varlistentry><term>When to Change</term><listitem><para>Increase or decrease the value of this parameter in response
to the volume of messages being logged by the client. Typically, you might
want to increase the value of this parameter to decrease the number of <literal>out
of space</literal> messages being  printed when a full file system on a server
is being actively used.</para>
</listitem>
</varlistentry><varlistentry><term>Commitment Level</term><listitem><para>Unstable</para>
</listitem>
</varlistentry><varlistentry><term>Change History</term><listitem><para>For information, see <olink targetptr="appendixa-50" remap="internal">nfs:nfs_write_error_interval
(Solaris 9 8/03)</olink>.</para>
</listitem>
</varlistentry>
</variablelist>
</sect2><sect2 id="chapter3-20"><title><literal>nfs:nfs_write_error_to_cons_only</literal></title><variablelist><varlistentry><term>Description</term><listitem><para>Controls whether NFS write errors are logged to the system console
and <command>syslog</command> or to the system console only. This parameter
affects messages for NFS version 2, 3, and 4 clients.</para>
</listitem>
</varlistentry><varlistentry><term>Data Type</term><listitem><para>Integer (32-bit)</para>
</listitem>
</varlistentry><varlistentry><term>Default</term><listitem><para>0 (system console and <command>syslog</command>)</para>
</listitem>
</varlistentry><varlistentry><term>Range</term><listitem><para>0 (system console and <command>syslog</command>) or 1 (system
console)</para>
</listitem>
</varlistentry><varlistentry><term>Units</term><listitem><para>Boolean values</para>
</listitem>
</varlistentry><varlistentry><term>Dynamic?</term><listitem><para>Yes</para>
</listitem>
</varlistentry><varlistentry><term>Validation</term><listitem><para>None</para>
</listitem>
</varlistentry><varlistentry><term>When to Change</term><listitem><para>Examine the value of this parameter to avoid filling up the
file system containing the messages logged by the <literal>syslogd</literal> daemon.
When this parameter is enabled, messages are printed on the system console
only and are not copied to the <command>syslog</command> messages file.</para>
</listitem>
</varlistentry><varlistentry><term>Commitment Level</term><listitem><para>Unstable</para>
</listitem>
</varlistentry><varlistentry><term>Change History</term><listitem><para>For information, see <olink targetptr="appendixa-51" remap="internal">nfs:nfs_write_error_to_cons_only
(Solaris 9 8/03)</olink>.</para>
</listitem>
</varlistentry>
</variablelist>
</sect2><sect2 id="chapter3-36"><title><literal>nfs:nfs_disable_rddir_cache</literal></title><variablelist><varlistentry><term>Description</term><listitem><para>Controls the use of a cache to hold responses from <literal>READDIR</literal> and <literal>READDIRPLUS</literal> requests. This cache avoids over-the-wire calls to the
server to retrieve directory information.</para>
</listitem>
</varlistentry><varlistentry><term>Data Type</term><listitem><para>Integer (32-bit)</para>
</listitem>
</varlistentry><varlistentry><term>Default</term><listitem><para>0 (caching enabled)</para>
</listitem>
</varlistentry><varlistentry><term>Range</term><listitem><para>0 (caching enabled) or 1 (caching disabled)</para>
</listitem>
</varlistentry><varlistentry><term>Units</term><listitem><para>Boolean values</para>
</listitem>
</varlistentry><varlistentry><term>Dynamic?</term><listitem><para>Yes</para>
</listitem>
</varlistentry><varlistentry><term>Validation</term><listitem><para>None</para>
</listitem>
</varlistentry><varlistentry><term>When to Change</term><listitem><para>Examine the value of this parameter if interoperability problems
develop due to a server that does not update the modification time on a directory
 when a file or directory is created in it or removed from it. The symptoms
are that new names do not appear in directory listings after they have been
added to the directory or that old names do not disappear after they have
been removed from the directory.</para><para>This parameter controls the caching for NFS version 2, 3, and 4 mounted
file systems. This parameter applies to all NFS mounted file systems, so caching
cannot be disabled or enabled on a per file system basis.</para><para>If you disable this parameter, you should also disable the following
parameters to to prevent bad entries in the DNLC negative cache:</para><itemizedlist><listitem><para><olink targetptr="chapter3-10" remap="internal">nfs:nfs_lookup_neg_cache</olink></para>
</listitem><listitem><para><olink targetptr="chapter3-11" remap="internal">nfs:nfs3_lookup_neg_cache</olink></para>
</listitem><listitem><para><olink targetptr="chapter3-29" remap="internal">nfs:nfs4_lookup_neg_cache</olink></para>
</listitem>
</itemizedlist>
</listitem>
</varlistentry><varlistentry><term>Commitment Level</term><listitem><para>Unstable</para>
</listitem>
</varlistentry><varlistentry><term>Change History</term><listitem><para>For information, see <olink targetptr="appendixa-52" remap="internal">nfs:nfs_disable_rddir_cache
(Solaris 9 8/03)</olink>.</para>
</listitem>
</varlistentry>
</variablelist>
</sect2><sect2 id="chapter3-57"><title><literal>nfs:nfs_bsize</literal></title><variablelist><varlistentry><term>Description</term><listitem><para>Controls the logical block size used by the NFS version 2 client.
This block size represents the amount of data that the client attempts to
read from or write to the server when it needs to do an I/O.</para>
</listitem>
</varlistentry><varlistentry><term>Data Type</term><listitem><para>Unsigned integer (32-bit)</para>
</listitem>
</varlistentry><varlistentry><term>Default</term><listitem><para>8192 bytes</para>
</listitem>
</varlistentry><varlistentry><term>Range</term><listitem><para>0 to 2<superscript>31</superscript> - 1</para>
</listitem>
</varlistentry><varlistentry><term>Units</term><listitem><para>Bytes</para>
</listitem>
</varlistentry><varlistentry><term>Dynamic?</term><listitem><para>Yes, but the block size for a file system is set when the
file system is mounted. To affect a particular file system, unmount and mount
the file system after changing this parameter.</para>
</listitem>
</varlistentry><varlistentry><term>Validation</term><listitem><para>None. Setting this parameter too low or too high might cause
the system to malfunction. Do not set this parameter to anything less than <literal>PAGESIZE</literal> for the specific platform. Do not set this parameter too
high because it might cause the system to hang while waiting for memory allocations
to be granted.</para>
</listitem>
</varlistentry><varlistentry><term>When to Change</term><listitem><para>Do not change this parameter.</para>
</listitem>
</varlistentry><varlistentry><term>Commitment Level</term><listitem><para>Unstable</para>
</listitem>
</varlistentry>
</variablelist>
</sect2><sect2 id="chapter3-35"><title><literal>nfs:nfs3_bsize</literal></title><variablelist><varlistentry><term>Description</term><listitem><para>Controls the logical block size used by the NFS version 3 client.
This block size represents the amount of data that the client attempts to
read from or write to the server when it needs to do an I/O.</para>
</listitem>
</varlistentry><varlistentry><term>Data Type</term><listitem><para>Unsigned integer (32-bit)</para>
</listitem>
</varlistentry><varlistentry><term>Default</term><listitem><para>32,768 (32 Kbytes)</para>
</listitem>
</varlistentry><varlistentry><term>Range</term><listitem><para>0 to 2<superscript>31</superscript> - 1</para>
</listitem>
</varlistentry><varlistentry><term>Units</term><listitem><para>Bytes</para>
</listitem>
</varlistentry><varlistentry><term>Dynamic?</term><listitem><para>Yes, but the block size for a file system is set when the
file system is mounted. To affect a particular file system, unmount and mount
the file system after changing this parameter.</para>
</listitem>
</varlistentry><varlistentry><term>Validation</term><listitem><para>None. Setting this parameter too low or too high might cause
the system to malfunction. Do not set this parameter to anything less than <literal>PAGESIZE</literal> for the specific platform. Do not set this parameter too
high because it might cause the system to hang while waiting for memory allocations
to be granted.</para>
</listitem>
</varlistentry><varlistentry><term>When to Change</term><listitem><para>Examine the value of this parameter when attempting to change
the maximum data transfer size. Change this parameter in conjunction with
the <literal>nfs:nfs3_max_transfer_size</literal> parameter. If larger transfers
are preferred, increase both parameters. If smaller transfers are preferred,
then just reducing this parameter should suffice.</para>
</listitem>
</varlistentry><varlistentry><term>Commitment Level</term><listitem><para>Unstable</para>
</listitem>
</varlistentry>
</variablelist>
</sect2><sect2 id="chapter3-37"><title><literal>nfs:nfs4_bsize</literal></title><variablelist><varlistentry><term>Description</term><listitem><para>Controls the logical block size used by the NFS version 4 client.
This block size represents the amount of data that the client attempts to
read from or write to the server when it needs to do an I/O.</para>
</listitem>
</varlistentry><varlistentry><term>Data Type</term><listitem><para>Unsigned integer (32-bit)</para>
</listitem>
</varlistentry><varlistentry><term>Default</term><listitem><para>32,768 (32 Kbytes)</para>
</listitem>
</varlistentry><varlistentry><term>Range</term><listitem><para>0 to 2<superscript>31</superscript> - 1</para>
</listitem>
</varlistentry><varlistentry><term>Units</term><listitem><para>Bytes</para>
</listitem>
</varlistentry><varlistentry><term>Dynamic?</term><listitem><para>Yes, but the block size for a file system is set when the
file system is mounted. To affect a particular file system, unmount and mount
the file system after changing this parameter.</para>
</listitem>
</varlistentry><varlistentry><term>Validation</term><listitem><para>None. Setting this parameter too low or too high might cause
the system to malfunction. Do not set this parameter to anything less than <literal>PAGESIZE</literal> for the specific platform. Do not set this parameter too
high because it might cause the system to hang while waiting for memory allocations
to be granted.</para>
</listitem>
</varlistentry><varlistentry><term>When to Change</term><listitem><para>Examine the value of this parameter when attempting to change
the maximum data transfer size. Change this parameter in conjunction with
the <literal>nfs:nfs4_max_transfer_size</literal> parameter. If larger transfers
are preferred, increase both parameters. If smaller transfers are preferred,
then just reducing this parameter should suffice.</para>
</listitem>
</varlistentry><varlistentry><term>Commitment Level</term><listitem><para>Unstable</para>
</listitem>
</varlistentry>
</variablelist>
</sect2><sect2 id="chapter3-51"><title><literal>nfs:nfs_async_clusters</literal></title><variablelist><varlistentry><term>Description</term><listitem><para>Controls the mix of asynchronous requests that are generated
by the NFS version 2 client. The four types of asynchronous requests are read-ahead,
putpage, pageio, and readdir-ahead. The client attempts to round-robin between
these different request types to attempt to be fair and not starve one request
type in favor of another.</para><para>However, the functionality in some NFS version 2 servers such as write
gathering depends upon certain behaviors of existing NFS Version 2 clients.
In particular, this functionality depends upon the client sending out multiple
WRITE requests at about the same time. If one request is taken out of the
queue at a time, the client would be defeating this server functionality designed
to enhance performance for the client.</para><para>Thus, use this parameter to control the number of requests of
each request type that are sent out before changing types.</para>
</listitem>
</varlistentry><varlistentry><term>Data Type</term><listitem><para>Unsigned integer (32-bit)</para>
</listitem>
</varlistentry><varlistentry><term>Default</term><listitem><para>1</para>
</listitem>
</varlistentry><varlistentry><term>Range</term><listitem><para>0 to 2<superscript>31</superscript> - 1</para>
</listitem>
</varlistentry><varlistentry><term>Units</term><listitem><para>Asynchronous requests</para>
</listitem>
</varlistentry><varlistentry><term>Dynamic?</term><listitem><para>Yes, but the cluster setting for a file system is set when
the file system is mounted. To affect a particular file system, unmount and
mount the file system after changing this parameter.</para>
</listitem>
</varlistentry><varlistentry><term>Validation</term><listitem><para>None. However, setting the value of this parameter to 0 causes
all of the queued requests of a particular request type to be processed before
moving on to the next type. This effectively disables the fairness portion
of the algorithm.</para>
</listitem>
</varlistentry><varlistentry><term>When to Change</term><listitem><para>To increase the number of each type of asynchronous request
that is generated before switching to the next type. Doing so might help with
server functionality that depends upon clusters of requests coming from the
client.</para>
</listitem>
</varlistentry><varlistentry><term>Commitment Level</term><listitem><para>Unstable</para>
</listitem>
</varlistentry>
</variablelist>
</sect2><sect2 id="chapter3-52"><title><literal>nfs:nfs3_async_clusters</literal></title><variablelist><varlistentry><term>Description</term><listitem><para>Controls the mix of asynchronous requests that are generated
by the NFS version 3 client. The five types of asynchronous requests are read-ahead,
putpage, pageio, readdir-ahead, and commit. The client attempts to round-robin
between these different request types to attempt to be fair and not starve
one request type in favor of another.</para><para>However, the functionality in some NFS version 3 servers such as write
gathering depends upon certain behaviors of existing NFS version 3 clients.
In particular, this functionality depends upon the client  sending out multiple
WRITE requests at about the same time.  If one request is taken out of the
queue at a time, the client would be defeating this server functionality designed
to enhance performance for the client.</para><para>Thus, use this parameter to control the number of requests of
each request type that are sent out before changing types.</para>
</listitem>
</varlistentry><varlistentry><term>Data Type</term><listitem><para>Unsigned integer (32-bit)</para>
</listitem>
</varlistentry><varlistentry><term>Default</term><listitem><para>1</para>
</listitem>
</varlistentry><varlistentry><term>Range</term><listitem><para>0 to 2<superscript>31</superscript> - 1</para>
</listitem>
</varlistentry><varlistentry><term>Units</term><listitem><para>Asynchronous requests</para>
</listitem>
</varlistentry><varlistentry><term>Dynamic?</term><listitem><para>Yes, but the cluster setting for a file system is set when
the file system is mounted. To affect a particular file system, unmount and
mount the file system after changing this parameter.</para>
</listitem>
</varlistentry><varlistentry><term>Validation</term><listitem><para>None. However, setting the value of this parameter to 0 causes
all of the queued requests of a particular request type to be processed before
moving on to the next type. This value effectively disables the fairness portion
of the algorithm.</para>
</listitem>
</varlistentry><varlistentry><term>When to Change</term><listitem><para>To increase the number of each type of asynchronous operation
that is generated before switching to the next type. Doing so might help with
server functionality that depends upon clusters of operations coming from
the client.</para>
</listitem>
</varlistentry><varlistentry><term>Commitment Level</term><listitem><para>Unstable</para>
</listitem>
</varlistentry>
</variablelist>
</sect2><sect2 id="chapter3-55"><title><literal>nfs:nfs4_async_clusters</literal></title><variablelist><varlistentry><term>Description</term><listitem><para>Controls the mix of asynchronous requests that are generated
by the NFS version 4 client. The six types of asynchronous requests are read-ahead,
putpage, pageio, readdir-ahead, commit, and inactive. The client attempts
to round-robin between these different request types to attempt to be fair
and not starve one request type in favor of another.</para><para>However, the functionality in some NFS version 4 servers such as write
gathering depends upon certain behaviors of existing NFS version 4 clients.
In particular, this functionality depends upon the client sending out multiple
WRITE requests at about the same time.  If one request is taken out of the
queue at a time, the client would be defeating this server functionality designed
to enhance performance for the client.</para><para>Thus, use this parameter to control the number of requests of
each request type that are sent out before changing types.</para>
</listitem>
</varlistentry><varlistentry><term>Data Type</term><listitem><para>Unsigned integer (32-bit)</para>
</listitem>
</varlistentry><varlistentry><term>Default</term><listitem><para>1</para>
</listitem>
</varlistentry><varlistentry><term>Range</term><listitem><para>0 to 2<superscript>31</superscript> - 1</para>
</listitem>
</varlistentry><varlistentry><term>Units</term><listitem><para>Asynchronous requests</para>
</listitem>
</varlistentry><varlistentry><term>Dynamic?</term><listitem><para>Yes, but the cluster setting for a file system is set when
the file system is mounted. To affect a particular file system, unmount and
mount the file system after changing this parameter.</para>
</listitem>
</varlistentry><varlistentry><term>Validation</term><listitem><para>None. However, setting the value of this parameter to 0 causes
all of the queued requests of a particular request type to be processed before
moving on to the next type. This effectively disables the fairness portion
of the algorithm.</para>
</listitem>
</varlistentry><varlistentry><term>When to Change</term><listitem><para>To increase the number of each type of asynchronous request
that is generated before switching to the next type. Doing so might help with
server functionality that depends upon clusters of requests coming from the
client.</para>
</listitem>
</varlistentry><varlistentry><term>Commitment Level</term><listitem><para>Unstable</para>
</listitem>
</varlistentry>
</variablelist>
</sect2><sect2 id="chapter3-53"><title><literal>nfs:nfs_async_timeout</literal></title><variablelist><varlistentry><term>Description</term><listitem><para>Controls the duration of time that threads, which execute asynchronous
I/O requests, sleep with nothing to do before exiting. When there are no more
requests to execute, each thread goes to sleep. If no new requests come in
before this timer expires, the thread wakes up and exits. If a request does
arrive, a thread is woken up to execute requests until there are none again.
Then, the thread goes back to sleep waiting for another request to arrive,
or for the timer to expire.</para>
</listitem>
</varlistentry><varlistentry><term>Data Type</term><listitem><para>Integer (32-bit)</para>
</listitem>
</varlistentry><varlistentry><term>Default</term><listitem><para>6000 (1 minute expressed as 60 sec * 100Hz)</para>
</listitem>
</varlistentry><varlistentry><term>Range</term><listitem><para>0 to 2<superscript>31</superscript> - 1</para>
</listitem>
</varlistentry><varlistentry><term>Units</term><listitem><para>Hz. (Typically, the clock runs at 100Hz.)</para>
</listitem>
</varlistentry><varlistentry><term>Dynamic?</term><listitem><para>Yes</para>
</listitem>
</varlistentry><varlistentry><term>Validation</term><listitem><para>None. However, setting this parameter to a non positive value
causes these threads exit as soon as there are no requests in the queue for
them to process.</para>
</listitem>
</varlistentry><varlistentry><term>When to Change</term><listitem><para>If the behavior of applications in the system is known precisely
and the rate of asynchronous I/O requests can be predicted, it might be possible
to tune this parameter to optimize performance slightly in either of the following
ways:</para><itemizedlist><listitem><para>By making the threads expire more quickly, thus freeing up
kernel resources more quickly</para>
</listitem><listitem><para>By making the threads expire more slowly, thus avoiding thread
create and destroy overhead</para>
</listitem>
</itemizedlist>
</listitem>
</varlistentry><varlistentry><term>Commitment Level</term><listitem><para>Unstable</para>
</listitem>
</varlistentry>
</variablelist>
</sect2><sect2 id="chapter3-54"><title><literal>nfs:nacache</literal></title><variablelist><varlistentry><term>Description</term><listitem><para>Tunes the number of hash queues that access the file access cache
on the NFS client. The file access cache stores file access rights that users
have with respect to files that they are trying to access. The cache itself
is dynamically allocated. However, the hash queues used to index into the
cache are statically allocated. The algorithm assumes that there is one access
cache entry per active file and four of these access cache entries per hash
bucket. Thus, by default, the value of this parameter is set to the value
of the <literal>nrnode</literal> parameter.</para>
</listitem>
</varlistentry><varlistentry><term>Data Type</term><listitem><para>Integer (32-bit)</para>
</listitem>
</varlistentry><varlistentry><term>Default</term><listitem><para>The default setting of this parameter is 0. This value means
that the value of <literal>nacache</literal> should be set to the value of
the <literal>nrnode</literal> parameter.</para>
</listitem>
</varlistentry><varlistentry><term>Range</term><listitem><para>1 to 2<superscript>31</superscript> - 1</para>
</listitem>
</varlistentry><varlistentry><term>Units</term><listitem><para>Access cache entries</para>
</listitem>
</varlistentry><varlistentry><term>Dynamic?</term><listitem><para>No. This value can only be changed by adding or changing the
parameter in the <filename>/etc/system</filename> file, and then rebooting
system.</para>
</listitem>
</varlistentry><varlistentry><term>Validation</term><listitem><para>None. However, setting this parameter to a negative value
will probably cause the system to try to allocate a very large set of hash
queues. While trying to do so, the system is likely to hang.</para>
</listitem>
</varlistentry><varlistentry><term>When to Change</term><listitem><para>Examine the value of this parameter if the basic assumption
of one access cache entry per file would be violated. This violation could
occur for systems in a timesharing mode where multiple users are accessing
the same file at about the same time. In this case, it might be helpful to
increase the expected size of the access cache so that the hashed access to
the cache stays efficient.</para>
</listitem>
</varlistentry><varlistentry><term>Commitment Level</term><listitem><para>Unstable</para>
</listitem>
</varlistentry>
</variablelist>
</sect2><sect2 id="chapter3-48"><title><literal>nfs:nfs3_jukebox_delay</literal></title><variablelist><varlistentry><term>Description</term><listitem><para>Controls the duration of time that the NFS version 3 client waits
to transmit a new request after receiving the <literal>NFS3ERR_JUKEBOX</literal> error
from a previous request. The <literal>NFS3ERR_JUKEBOX</literal> error is generally
returned from the server when the file is temporarily unavailable for some
reason. This error is generally associated with hierarchical storage, and
CD or tape jukeboxes.</para>
</listitem>
</varlistentry><varlistentry><term>Data Type</term><listitem><para>Long integer (32 bits on 32-bit platforms and 64 bits on 64-bit
platforms)</para>
</listitem>
</varlistentry><varlistentry><term>Default</term><listitem><para>1000 (10 seconds expressed as 10 sec * 100Hz)</para>
</listitem>
</varlistentry><varlistentry><term>Range</term><listitem><para>0 to 2<superscript>31</superscript> - 1 on 32-bit platforms</para><para>0 to 2<superscript>63</superscript> - 1 on 64-bit platforms</para>
</listitem>
</varlistentry><varlistentry><term>Units</term><listitem><para>Hz. (Typically, the clock runs at 100Hz.)</para>
</listitem>
</varlistentry><varlistentry><term>Dynamic?</term><listitem><para>Yes</para>
</listitem>
</varlistentry><varlistentry><term>Validation</term><listitem><para>None</para>
</listitem>
</varlistentry><varlistentry><term>When to Change</term><listitem><para>Examine the value of this parameter and perhaps adjust it
to match the behaviors exhibited by the server. Increase this value if the
delays in making the file available are long in order to reduce network overhead
due to repeated retransmissions. Decrease this value to reduce the delay in
discovering that the file has become available.</para>
</listitem>
</varlistentry><varlistentry><term>Commitment Level</term><listitem><para>Unstable</para>
</listitem>
</varlistentry>
</variablelist>
</sect2><sect2 id="chapter3-49"><title><literal>nfs:nfs3_max_transfer_size</literal></title><variablelist><varlistentry><term>Description</term><listitem><para>Controls the maximum size of the data portion of an NFS version
3 <literal>READ</literal>, <literal>WRITE</literal>, <literal>READDIR</literal>,
or <literal>READDIRPLUS</literal> request. This parameter controls both the
maximum size of the request that the server returns as well as the maximum
size of the request that the client generates.</para>
</listitem>
</varlistentry><varlistentry><term>Data Type</term><listitem><para>Integer (32-bit)</para>
</listitem>
</varlistentry><varlistentry><term>Default</term><listitem><para>1,048,576
(1 Mbyte)</para>
</listitem>
</varlistentry><varlistentry><term>Range</term><listitem><para>0 to 2<superscript>31</superscript> - 1</para>
</listitem>
</varlistentry><varlistentry><term>Units</term><listitem><para>Bytes</para>
</listitem>
</varlistentry><varlistentry><term>Dynamic?</term><listitem><para>Yes, but this parameter is set per file system at mount time.
To     affect a particular file system, unmount and mount the file system
after changing this parameter.</para>
</listitem>
</varlistentry><varlistentry><term>Validation</term><listitem><para>None. However, setting the maximum transfer size on the server
to 0 is likely to cause clients to malfunction or just decide not to attempt
to talk to the server.</para><para>There is also a limit on the maximum transfer size when using NFS over
the UDP transport. UDP has a hard limit of 64 Kbytes per datagram. This 64
Kbytes must include the RPC header as well as other NFS information, in addition
to the data portion of the request. Setting the limit too high might result
in errors from UDP and communication problems between the client and the server.</para>
</listitem>
</varlistentry><varlistentry><term>When to Change</term><listitem><para>To tune the size of data transmitted over the network. In
general, the <literal>nfs:nfs3_bsize</literal> parameter should also be updated
to reflect changes in this parameter. </para><para>For example, when you attempt to increase the transfer size beyond 32
Kbytes, update <literal>nfs:nfs3_bsize</literal> to reflect the increased
value. Otherwise, no change in the over-the-wire request size is observed.
For more information, see <olink targetptr="chapter3-35" remap="internal">nfs:nfs3_bsize</olink>.</para><para>If you want to use a smaller transfer size than the default transfer
size, use the <command>mount</command> command's <option>wsize</option> or <option>rsize</option> option on a per-file system basis.</para>
</listitem>
</varlistentry><varlistentry><term>Commitment Level</term><listitem><para>Unstable</para>
</listitem>
</varlistentry><varlistentry><term>Change History</term><listitem><para>For information, see <olink targetptr="appendixa-53" remap="internal">nfs:nfs3_max_transfer_size
(Solaris 9 8/03)</olink>.</para>
</listitem>
</varlistentry>
</variablelist>
</sect2><sect2 id="chapter3-73"><title><literal>nfs:nfs4_max_transfer_size</literal></title><variablelist><varlistentry><term>Description</term><listitem><para>Controls the maximum size of the data portion of an NFS version
4 <literal>READ</literal>, <literal>WRITE</literal>, <literal>READDIR</literal>,
or <literal>READDIRPLUS</literal> request. This parameter controls both the
maximum size of the request that the server returns as well as the maximum
size of the request that the client generates.</para>
</listitem>
</varlistentry><varlistentry><term>Data Type</term><listitem><para>Integer (32-bit)</para>
</listitem>
</varlistentry><varlistentry><term>Default</term><listitem><para>32, 768 (32 Kbytes)</para>
</listitem>
</varlistentry><varlistentry><term>Range</term><listitem><para>0 to 2<superscript>31</superscript> - 1</para>
</listitem>
</varlistentry><varlistentry><term>Units</term><listitem><para>Bytes</para>
</listitem>
</varlistentry><varlistentry><term>Dynamic?</term><listitem><para>Yes, but this parameter is set per file system at mount time.
To  affect a particular file system, unmount and mount the file system after
changing this parameter.</para>
</listitem>
</varlistentry><varlistentry><term>Validation</term><listitem><para>None. However, setting the maximum transfer size on the server
to 0 is likely to cause clients to malfunction or just decide not to attempt
to talk to the server.</para><para>There is also a limit on the maximum transfer size when using NFS over
the UDP transport. For more information on the maximum for UDP, see <olink targetptr="chapter3-49" remap="internal">nfs:nfs3_max_transfer_size</olink>.</para>
</listitem>
</varlistentry><varlistentry><term>When to Change</term><listitem><para>To tune the size of data transmitted over the network. In
general, the <literal>nfs:nfs4_bsize</literal> parameter should also be updated
to reflect changes in this parameter.</para><para>For example, when you attempt to increase the transfer size beyond 32
Kbytes, update <literal>nfs:nfs4_bsize</literal> to reflect the increased
value. Otherwise, no change in the over-the-wire request size is observed.
For more information, see <olink targetptr="chapter3-37" remap="internal">nfs:nfs4_bsize</olink>.</para><para>If you want to use a smaller transfer size than the default transfer
size, use the <command>mount</command> command's <option>wsize</option> or <option>rsize</option> option on a per-file system basis.</para>
</listitem>
</varlistentry><varlistentry><term>Commitment Level</term><listitem><para>Unstable</para>
</listitem>
</varlistentry>
</variablelist>
</sect2><sect2 id="chapter3-45"><title><literal>nfs:nfs3_max_transfer_size_clts</literal></title><variablelist><varlistentry><term>Description</term><listitem><para>Controls the maximum size of the data portion of an NFS version
3 <literal>READ</literal>, <literal>WRITE</literal>, <literal>READDIR</literal>,
or <literal>READDIRPLUS</literal> request over UDP. This parameter controls
both the maximum size of the request that the server returns as well as the
maximum size of the request that the client generates.</para>
</listitem>
</varlistentry><varlistentry><term>Data Type</term><listitem><para>Integer (32-bit)</para>
</listitem>
</varlistentry><varlistentry><term>Default</term><listitem><para>32, 768 (32 Kbytes)</para>
</listitem>
</varlistentry><varlistentry><term>Range</term><listitem><para>0 to 2<superscript>31</superscript> - 1</para>
</listitem>
</varlistentry><varlistentry><term>Units</term><listitem><para>Bytes</para>
</listitem>
</varlistentry><varlistentry><term>Dynamic?</term><listitem><para>Yes, but this parameter is set per file system at mount time.
To     affect a particular file system, unmount and mount the file system
after changing this parameter.</para>
</listitem>
</varlistentry><varlistentry><term>Validation</term><listitem><para>None. However, setting the maximum transfer size on the server
to 0 is likely to cause clients to malfunction or just decide not to attempt
to talk to the server.</para>
</listitem>
</varlistentry><varlistentry><term>When to Change</term><listitem><para>Do not change this parameter.</para>
</listitem>
</varlistentry><varlistentry><term>Commitment Level</term><listitem><para>Unstable</para>
</listitem>
</varlistentry>
</variablelist>
</sect2><sect2 id="chapter3-58"><title><literal>nfs:nfs3_max_transfer_size_cots</literal></title><variablelist><varlistentry><term>Description</term><listitem><para>Controls the maximum size of the data portion of an NFS version
3 <literal>READ</literal>, <literal>WRITE</literal>, <literal>READDIR</literal>,
or <literal>READDIRPLUS</literal> request over TCP. This parameter controls
both the maximum size of the request that the server returns as well as the
maximum size of the request that the client generates.</para>
</listitem>
</varlistentry><varlistentry><term>Data Type</term><listitem><para>Integer (32-bit)</para>
</listitem>
</varlistentry><varlistentry><term>Default</term><listitem><para>1048576 bytes</para>
</listitem>
</varlistentry><varlistentry><term>Range</term><listitem><para>0 to 2<superscript>31</superscript> - 1</para>
</listitem>
</varlistentry><varlistentry><term>Units</term><listitem><para>Bytes</para>
</listitem>
</varlistentry><varlistentry><term>Dynamic?</term><listitem><para>Yes, but this parameter is set per file system at mount time.
To     affect a particular file system, unmount and mount the file system
after changing this parameter.</para>
</listitem>
</varlistentry><varlistentry><term>Validation</term><listitem><para>None. However, setting the maximum transfer size on the server
to 0 is likely to cause clients to malfunction or just decide not to attempt
to talk to the server.</para>
</listitem>
</varlistentry><varlistentry><term>When to Change</term><listitem><para>Do not change this parameter unless transfer sizes larger
than 1 Mbyte are preferred.</para>
</listitem>
</varlistentry><varlistentry><term>Commitment Level</term><listitem><para>Unstable</para>
</listitem>
</varlistentry>
</variablelist>
</sect2>
</sect1><sect1 id="chapter3-22"><title><literal>nfssrv</literal> Module Parameters</title><para>This section describes NFS parameters for the <literal>nfssrv</literal> module.</para><sect2 id="chapter3-21"><title><literal>nfssrv:nfs_portmon</literal></title><variablelist><varlistentry><term>Description</term><listitem><para>Controls some security checking that the NFS server attempts to
do to enforce integrity on the part of its clients. The NFS server can check
whether the source port from which a request was sent was a <emphasis>reserved
port</emphasis>. A reserved port has a number less than 1024. For BSD-based
systems, these ports are reserved for processes being run by root. This security
checking can prevent users from writing their own RPC-based applications that
defeat the access checking that the NFS client uses.</para>
</listitem>
</varlistentry><varlistentry><term>Data Type</term><listitem><para>Integer (32-bit)</para>
</listitem>
</varlistentry><varlistentry><term>Default</term><listitem><para>0 (security checking disabled)</para>
</listitem>
</varlistentry><varlistentry><term>Range</term><listitem><para>0 (security checking disabled) or 1 (security checking enabled)</para>
</listitem>
</varlistentry><varlistentry><term>Units</term><listitem><para>Boolean values</para>
</listitem>
</varlistentry><varlistentry><term>Dynamic?</term><listitem><para>Yes</para>
</listitem>
</varlistentry><varlistentry><term>Validation</term><listitem><para>None</para>
</listitem>
</varlistentry><varlistentry><term>When to Change</term><listitem><para>Use this parameter to prevent malicious users from gaining
access to files by using the NFS server that they would not ordinarily have
access to. However, the <emphasis>reserved port</emphasis> notion is not universally
supported. Thus, the security aspects of the check are very weak. Also, not
all NFS client implementations bind their transport endpoints to a port number
in the reserved range. Thus, interoperability problems might result if the
security checking is enabled.</para>
</listitem>
</varlistentry><varlistentry><term>Commitment Level</term><listitem><para>Unstable</para>
</listitem>
</varlistentry>
</variablelist>
</sect2><sect2 id="chapter3-25"><title><literal>nfssrv:rfs_write_async</literal></title><variablelist><varlistentry><term>Description</term><listitem><para>Controls the behavior of the NFS version 2 server when it
processes <literal>WRITE</literal> requests. The NFS version 2 protocol mandates
that all modified data and metadata associated with the <literal>WRITE</literal> request
reside on stable storage before the server can respond to the client. NFS
version 2 <literal>WRITE</literal> requests are limited to 8192 bytes of data.
Thus, each <literal>WRITE</literal> request might cause multiple small writes
to the storage subsystem. This can cause a performance problem.</para><para>One method to accelerate NFS version 2 <literal>WRITE</literal> requests
is to take advantage of a client behavior. Clients tend to send <literal>WRITE</literal> requests
in batches. The server can take advantage of this behavior by clustering together
the different <literal>WRITE</literal> requests into a single request to the
underlying file system. Thus, the data to be written to the storage subsystem
can be written in fewer, larger requests. This method can significantly increase
the throughput for <literal>WRITE</literal> requests.</para>
</listitem>
</varlistentry><varlistentry><term>Data Type</term><listitem><para>Integer (32-bit)</para>
</listitem>
</varlistentry><varlistentry><term>Default</term><listitem><para>1 (clustering enabled)</para>
</listitem>
</varlistentry><varlistentry><term>Range</term><listitem><para>0 (clustering disabled) or 1 (clustering enabled)</para>
</listitem>
</varlistentry><varlistentry><term>Units</term><listitem><para>Boolean values</para>
</listitem>
</varlistentry><varlistentry><term>Dynamic?</term><listitem><para>Yes</para>
</listitem>
</varlistentry><varlistentry><term>Validation</term><listitem><para>None</para>
</listitem>
</varlistentry><varlistentry><term>When to Change</term><listitem><para>Some very small NFS clients, particularly PC clients, might
not batch <literal>WRITE</literal> requests. Thus, the behavior required from
the clients might not exist. In addition, the clustering in the NFS version
2 server might just add overhead and slow down performance instead of increasing
it.</para>
</listitem>
</varlistentry><varlistentry><term>Commitment Level</term><listitem><para>Unstable</para>
</listitem>
</varlistentry>
</variablelist>
</sect2><sect2 id="chapter3-46"><title><literal>nfssrv:nfsauth_ch_cache_max</literal></title><variablelist><varlistentry><term>Description</term><listitem><para>Controls the size of the cache of client handles that contact
the NFS authentication server. This server authenticates NFS clients to determine
whether they are allowed access to the file handle that they are trying to
use.</para>
</listitem>
</varlistentry><varlistentry><term>Data Type</term><listitem><para>Integer (32-bit)</para>
</listitem>
</varlistentry><varlistentry><term>Default</term><listitem><para>16</para>
</listitem>
</varlistentry><varlistentry><term>Range</term><listitem><para>0 to 2<superscript>31</superscript> - 1</para>
</listitem>
</varlistentry><varlistentry><term>Units</term><listitem><para>Client handles</para>
</listitem>
</varlistentry><varlistentry><term>Dynamic?</term><listitem><para>Yes</para>
</listitem>
</varlistentry><varlistentry><term>Validation</term><listitem><para>None</para>
</listitem>
</varlistentry><varlistentry><term>When to Change</term><listitem><para>This cache is not dynamic, so attempts to allocate a client
handle when all are busy will fail. This failure results in requests being
dropped by the NFS server because they could not be authenticated. Most often,
this result is not a problem because the NFS client just times out and retransmits
the request. However, for soft-mounted file systems on the client, the client
might time out, not retry the request, and then return an error to the application.
This situation might be avoided if you ensure that the size of the cache on
the server is large enough to handle the load.</para>
</listitem>
</varlistentry><varlistentry><term>Commitment Level</term><listitem><para>Unstable</para>
</listitem>
</varlistentry>
</variablelist>
</sect2><sect2 id="chapter3-47"><title><literal>nfssrv:exi_cache_time</literal></title><variablelist><varlistentry><term>Description</term><listitem><para>Controls the duration of time that entries are held in the NFS
authentication cache before being purged due to memory pressure in the system.</para>
</listitem>
</varlistentry><varlistentry><term>Data Type</term><listitem><para>Long integer (32 bits on 32-bit platforms and 64 bits on 64-bit
platforms)</para>
</listitem>
</varlistentry><varlistentry><term>Default</term><listitem><para>3600 seconds (1 hour)</para>
</listitem>
</varlistentry><varlistentry><term>Range</term><listitem><para>0 to 2<superscript>31</superscript> - 1 on 32-bit platforms</para><para>0 to 2<superscript>63</superscript> - 1 on 64-bit platforms</para>
</listitem>
</varlistentry><varlistentry><term>Units</term><listitem><para>Seconds</para>
</listitem>
</varlistentry><varlistentry><term>Dynamic?</term><listitem><para>Yes</para>
</listitem>
</varlistentry><varlistentry><term>Validation</term><listitem><para>None</para>
</listitem>
</varlistentry><varlistentry><term>When to Change</term><listitem><para>The size of the NFS authentication cache can be adjusted by
varying the minimum age of entries that can get purged from the cache. The
size of the cache should be controlled so that it is not allowed to grow 
too large, thus using system resources that are not allowed to be released
due to this aging process.</para>
</listitem>
</varlistentry><varlistentry><term>Commitment Level</term><listitem><para>Unstable</para>
</listitem>
</varlistentry>
</variablelist>
</sect2>
</sect1><sect1 id="chapter3-27"><title><literal>rpcmod</literal> Module Parameters</title><para>This section describes NFS parameters for the <literal>rpcmod</literal> module.</para><sect2 id="chapter3-26"><title><literal>rpcmod:clnt_max_conns</literal></title><variablelist><varlistentry><term>Description</term><listitem><para>Controls the number of TCP connections that the NFS client uses
when communicating with each NFS server. The kernel RPC is constructed so
that it can multiplex RPCs over a single connection. However, multiple connections
can be used, if preferred.</para>
</listitem>
</varlistentry><varlistentry><term>Data Type</term><listitem><para>Integer (32-bit)</para>
</listitem>
</varlistentry><varlistentry><term>Default</term><listitem><para>1</para>
</listitem>
</varlistentry><varlistentry><term>Range</term><listitem><para>1 to 2<superscript>31</superscript> - 1</para>
</listitem>
</varlistentry><varlistentry><term>Units</term><listitem><para>Connections</para>
</listitem>
</varlistentry><varlistentry><term>Dynamic?</term><listitem><para>Yes</para>
</listitem>
</varlistentry><varlistentry><term>Validation</term><listitem><para>None</para>
</listitem>
</varlistentry><varlistentry><term>When to Change</term><listitem><para>In general, one connection is sufficient to achieve full network
bandwidth. However, if TCP cannot utilize the bandwidth offered by the network
in a single stream, then multiple connections might increase the throughput
between the client and the server.</para><para>Increasing the number of connections doesn't come without consequences.
Increasing the number of connections also increases kernel resource usage
needed to keep track of each connection.</para>
</listitem>
</varlistentry><varlistentry><term>Commitment Level</term><listitem><para>Unstable</para>
</listitem>
</varlistentry>
</variablelist>
</sect2><sect2 id="chapter3-39"><title><literal>rpcmod:clnt_idle_timeout</literal></title><variablelist><varlistentry><term>Description</term><listitem><para>Controls the duration of time on the client that a connection
between the client and server is allowed to remain idle before being closed.</para>
</listitem>
</varlistentry><varlistentry><term>Data Type</term><listitem><para>Long integer (32 bits on 32-bit platforms and 64 bits  on
64-bit platforms)</para>
</listitem>
</varlistentry><varlistentry><term>Default</term><listitem><para>300,000 milliseconds (5 minutes)</para>
</listitem>
</varlistentry><varlistentry><term>Range</term><listitem><para>0 to 2<superscript>31</superscript> - 1 on 32-bit platforms</para><para>0 to 2<superscript>63</superscript> - 1 on 64-bit platforms</para>
</listitem>
</varlistentry><varlistentry><term>Units</term><listitem><para>Milliseconds</para>
</listitem>
</varlistentry><varlistentry><term>Dynamic?</term><listitem><para>Yes</para>
</listitem>
</varlistentry><varlistentry><term>Validation</term><listitem><para>None</para>
</listitem>
</varlistentry><varlistentry><term>When to Change</term><listitem><para>Use this parameter to change the time that idle connections
are allowed to exist on the client before being closed. You might might want
to close connections at a faster rate to avoid consuming system resources.</para>
</listitem>
</varlistentry><varlistentry><term>Commitment Level</term><listitem><para>Unstable</para>
</listitem>
</varlistentry>
</variablelist>
</sect2><sect2 id="chapter3-40"><title><literal>rpcmod:svc_idle_timeout</literal></title><variablelist><varlistentry><term>Description</term><listitem><para>Controls the duration of time on the server that a connection
between the client and server is allowed to remain idle before being closed.</para>
</listitem>
</varlistentry><varlistentry><term>Data Type</term><listitem><para>Long integer (32 bits on 32-bit platforms and 64 bits on 64-bit
platforms)</para>
</listitem>
</varlistentry><varlistentry><term>Default</term><listitem><para>360,000 milliseconds (6 minutes)</para>
</listitem>
</varlistentry><varlistentry><term>Range</term><listitem><para>0 to 2<superscript>31</superscript> - 1 on 32-bit platforms</para><para>0 to 2<superscript>63</superscript> - 1 on 64-bit platforms</para>
</listitem>
</varlistentry><varlistentry><term>Units</term><listitem><para>Milliseconds</para>
</listitem>
</varlistentry><varlistentry><term>Dynamic?</term><listitem><para>Yes</para>
</listitem>
</varlistentry><varlistentry><term>Validation</term><listitem><para>None</para>
</listitem>
</varlistentry><varlistentry><term>When to Change</term><listitem><para>Use this parameter to change the time that idle connections
are allowed to exist on the server before being closed. You might want to
close connections at a faster rate to avoid consuming system resources.</para>
</listitem>
</varlistentry><varlistentry><term>Commitment Level</term><listitem><para>Unstable</para>
</listitem>
</varlistentry>
</variablelist>
</sect2><sect2 id="chapter3-41"><title><literal>rpcmod:svc_default_stksize</literal></title><variablelist><varlistentry><term>Description</term><listitem><para>Sets the size of the kernel stack for kernel RPC service threads.</para>
</listitem>
</varlistentry><varlistentry><term>Data Type</term><listitem><para>Integer (32-bit)</para>
</listitem>
</varlistentry><varlistentry><term>Default</term><listitem><para>The default value is 0. This value means that the stack size
is set to the system default.</para>
</listitem>
</varlistentry><varlistentry><term>Range</term><listitem><para>0 to 2<superscript>31</superscript> - 1</para>
</listitem>
</varlistentry><varlistentry><term>Units</term><listitem><para>Bytes</para>
</listitem>
</varlistentry><varlistentry><term>Dynamic?</term><listitem><para>Yes, for all new threads that are allocated. The stack size
is set when the thread is created. Therefore, changes to this parameter do
not affect existing threads but are applied to all new threads that are allocated.</para>
</listitem>
</varlistentry><varlistentry><term>Validation</term><listitem><para>None</para>
</listitem>
</varlistentry><varlistentry><term>When to Change</term><listitem><para>Very deep call depths can cause the stack to overflow and
cause red zone faults. The combination of a fairly deep call depth for the
transport, coupled with a deep call depth for the local file system, can cause
NFS service threads to overflow their stacks.</para><para>Set this parameter to a multiple of the hardware <literal>pagesize</literal> on
the platform.</para>
</listitem>
</varlistentry><varlistentry><term>Commitment Level</term><listitem><para>Unstable</para>
</listitem>
</varlistentry>
</variablelist>
</sect2><sect2 id="chapter3-34"><title><literal>rpcmod:svc_default_max_same_xprt</literal></title><variablelist><varlistentry><term>Description</term><listitem><para>Controls the maximum number of requests that are processed
for each transport endpoint before switching transport endpoints. The kernel
RPC works by having a pool of service threads and a pool of transport endpoints.
Any one of the service threads can process requests from any one of the transport
endpoints.  For performance, multiple requests on each transport endpoint
are consumed before switching to a different transport endpoint. This approach
offers performance benefits while avoiding starvation.</para>
</listitem>
</varlistentry><varlistentry><term>Data Type</term><listitem><para>Integer (32-bit)</para>
</listitem>
</varlistentry><varlistentry><term>Default</term><listitem><para>8</para>
</listitem>
</varlistentry><varlistentry><term>Range</term><listitem><para>0 to 2<superscript>31</superscript> - 1</para>
</listitem>
</varlistentry><varlistentry><term>Units</term><listitem><para>Requests</para>
</listitem>
</varlistentry><varlistentry><term>Dynamic?</term><listitem><para>Yes, but the maximum number of requests to process before
switching transport endpoints is set when the transport endpoint is configured
into the kernel RPC subsystem. Changes to this parameter only affect new transport
endpoints, not existing transport endpoints.</para>
</listitem>
</varlistentry><varlistentry><term>Validation</term><listitem><para>None</para>
</listitem>
</varlistentry><varlistentry><term>When to Change</term><listitem><para>Tune this parameter so that services can take advantage of
client behaviors such as the clustering that accelerate NFS version 2 <literal>WRITE</literal> requests. Increasing this parameter might result in the server
being better able to take advantage of client behaviors.</para>
</listitem>
</varlistentry><varlistentry><term>Commitment Level</term><listitem><para>Unstable</para>
</listitem>
</varlistentry>
</variablelist>
</sect2><sect2 id="chapter3-43"><title><literal>rpcmod:maxdupreqs</literal></title><variablelist><varlistentry><term>Description</term><listitem><para>Controls the size of the duplicate request cache that detects
RPC- level retransmissions on connectionless transports. This cache is indexed
by the client network address and the RPC procedure number, program number,
version number, and transaction ID. This cache avoids processing retransmitted
requests that might not be idempotent.</para>
</listitem>
</varlistentry><varlistentry><term>Data Type</term><listitem><para>Integer (32-bit)</para>
</listitem>
</varlistentry><varlistentry><term>Default</term><listitem><para>1024</para>
</listitem>
</varlistentry><varlistentry><term>Range</term><listitem><para>1 to 2<superscript>31</superscript> - 1</para>
</listitem>
</varlistentry><varlistentry><term>Units</term><listitem><para>Requests</para>
</listitem>
</varlistentry><varlistentry><term>Dynamic?</term><listitem><para>The cache is dynamically sized, but the hash queues that provide
fast access to the cache are statically sized. Making the cache very large
might result in long search times to find entries in the cache.</para><para>Do not set the value of this parameter to 0. This value prevents the
NFS server from handling non idempotent requests.</para>
</listitem>
</varlistentry><varlistentry><term>Validation</term><listitem><para>None</para>
</listitem>
</varlistentry><varlistentry><term>When to Change</term><listitem><para>Examine the value of this parameter if false failures are
encountered by NFS clients. For example, if an attempt to create a directory
fails, but the directory is actually created, perhaps that retransmitted <literal>MKDIR</literal> request was not detected by the server.</para><para>The size of the cache should match the load on the server. The cache
records non idempotent requests and so only needs to track a portion of the
total requests. The cache does need to hold the information long enough to
be able to detect a retransmission by the client. Typically, the client timeout
for connectionless transports is relatively short, starting around 1 second
and increasing to about 20 seconds.</para>
</listitem>
</varlistentry><varlistentry><term>Commitment Level</term><listitem><para>Unstable</para>
</listitem>
</varlistentry>
</variablelist>
</sect2><sect2 id="chapter3-44"><title><literal>rpcmod:cotsmaxdupreqs</literal></title><variablelist><varlistentry><term>Description</term><listitem><para>Controls the size of the duplicate request cache that detects
RPC- level retransmissions on connection-oriented transports. This cache is
indexed by the client network address and the RPC procedure number, program
number, version number, and transaction ID. This cache avoids processing retransmitted
requests that might not be idempotent.</para>
</listitem>
</varlistentry><varlistentry><term>Data Type</term><listitem><para>Integer (32&ndash;bit)</para>
</listitem>
</varlistentry><varlistentry><term>Default</term><listitem><para>1024</para>
</listitem>
</varlistentry><varlistentry><term>Range</term><listitem><para>1 to 2<superscript>31</superscript> - 1</para>
</listitem>
</varlistentry><varlistentry><term>Units</term><listitem><para>Requests</para>
</listitem>
</varlistentry><varlistentry><term>Dynamic?</term><listitem><para>Yes</para>
</listitem>
</varlistentry><varlistentry><term>Validation</term><listitem><para>The cache is dynamically sized, but the hash queues that provide
fast access to the cache are statically sized. Making the cache very large
might result in long search times to find entries in the cache.</para><para>Do not set the value of this parameter to 0. It prevents the NFS server
from handling non-idempotent requests.</para>
</listitem>
</varlistentry><varlistentry><term>When to Change</term><listitem><para>Examine the value of this parameter if false failures are
encountered by NFS clients. For example, if an attempt to create a directory
fails, but the directory is actually created, it is possible that a retransmitted <literal>MKDIR</literal> request was not detected by the server.</para><para>The size of the cache should match the load on the server. The cache
records non-idempotent requests and so only needs to track a portion of the
total requests. It does need to hold the information long enough to be able
to detect a retransmission on the part of the client. Typically, the client
timeout for connection oriented transports is very long, about 1 minute. Thus,
entries need to stay in the cache for fairly long times.</para>
</listitem>
</varlistentry><varlistentry><term>Commitment Level</term><listitem><para>Unstable</para>
</listitem>
</varlistentry>
</variablelist>
</sect2>
</sect1>
</chapter>