<sect1 id="performance">
<!--O
 <title>Optimizing NFS Performance</title>
-->
 <title>NFS の性能を最適化する</title>
 <para>
<!--O
Careful analysis of your environment, both from the client and from the server
point of view, is the first step necessary for optimal NFS performance. The
first sections will address issues that are generally important to the client.
Later (<xref linkend="frag-overflow"> and beyond), server side issues 
will be discussed. In both
cases, these issues will not be limited exclusively to one side or the other,
but it is useful to separate the two in order to get a clearer picture of
cause and effect.
-->
クライアントとサーバの両面から、環境を注意深く分析することが、
NFS の性能を最適化する際の最初のステップになります。
前半のセクションでは、一般にクライアントの方で重要になる点を扱います。
後半 (<xref linkend="frag-overflow"> 以降) では、サーバ側の点を議論します。
サーバ・クライアント両側での項目は、
互いに影響を及ぼしあうことがないわけではありませんが、
原因・結果をはっきりさせるためには、この 2 つを分けておくと便利かと思います。
</para>
<para>
<!--O
Aside from the general network configuration - appropriate network capacity,
faster NICs, full duplex settings in order to reduce collisions, agreement in
network speed among the switches and hubs, etc. - one of the most important
client optimization settings are the NFS data transfer buffer sizes, specified
by the <command>mount</command> command options <userinput>rsize</userinput>
and <userinput>wsize</userinput>.
-->
十分なネットワーク容量、高速な NIC、全二重の設定にして衝突を減らす、
スイッチやハブでネットワークスピードを一致させる、
といったようなネットワーク関連の設定を除くと、
クライアントを最適化するために最も重要な設定は、
NFS データ転送のバッファサイズでしょう。
これは <command>mount</command> コマンドの
<userinput>rsize</userinput>, <userinput>wsize</userinput>
各オプションで設定します。
</para>

<sect2 id="blocksizes">
<!--O
 <title>Setting Block Size to Optimize Transfer Speeds</title>
-->
 <title>ブロックサイズを設定して転送速度を最適化する</title>
 <para>
<!--O
The <command>mount</command> command options <userinput>rsize</userinput> 
and <userinput>wsize</userinput> specify the size of the chunks of
data that the client and server pass back and forth 
to each other. If no <userinput>rsize</userinput>
and <userinput>wsize</userinput> options are specified, 
the default varies by which version of NFS we
are using. The most common default is 4K (4096 bytes), although for TCP-based
mounts in 2.2 kernels, and for all mounts beginning with 2.4 kernels, the
server specifies the default block size.
-->
<command>mount</command> コマンドの
<userinput>rsize</userinput> オプションと
<userinput>wsize</userinput> オプションは、
クライアントとサーバがデータをやりとりするときの
データの転送単位を指定するものです。
それぞれのオプションが指定されないときのデフォルト値は、
使っている NFS のバージョンによって異なります。
ほとんどの場合のデフォルトは 4K (4096 バイト) ですが、
2.2 カーネルにおける TCP ベースでのマウントや、
2.4 カーネル以降でのあらゆるマウントでは、
サーバがデフォルトのブロックサイズを指定します。
</para>
<para>
<!--O
The theoretical limit for the NFS V2 protocol is 8K. For the V3 protocol, the
limit is specific to the server. On the Linux server, the maximum block size
is defined by the value of the kernel constant 
<userinput>NFSSVC_MAXBLKSIZE</userinput>, found in the
Linux kernel source file <filename>./include/linux/nfsd/const.h</filename>.
The current maximum block size for the kernel, as of 2.4.17, is 8K (8192 bytes),
but the patch set implementing NFS over TCP/IP transport in the 2.4 
series, as of this writing, uses a value of 32K (defined in the
patch as 32*1024) for the maximum block size.
-->
NFS V2 プロトコルの理論上の上限は 8K です。
V3 プロトコルでの上限はサーバによって異なります。
Linux サーバでの最大ブロックサイズは、
カーネルソースの
<filename>./include/linux/nfsd/const.h</filename> にあるカーネル定数
<userinput>NFSSVC_MAXBLKSIZE</userinput> で決まります。
2.4.17 の時点では、カーネルの最大ブロックサイズは 8K (8192 バイト) ですが、
2.4 系に対する NFS over TCP/IP 転送を実装したパッチでは、
執筆時点で 32K (このパッチでは 32*1024) が最大ブロックサイズになっています。
</para>
<para>
<!--O
All 2.4 clients currently support up to 32K block transfer sizes, allowing the
standard 32K block transfers across NFS mounts from other servers, such as
Solaris, without client modification.
-->
すべての 2.4 系クライアントは、現時点で最大
32 K までのブロック転送サイズをサポートしており、
Solaris のような他のサーバからの NFS 転送で標準となっている
32K のブロック転送を、クライアントを修正することなく利用できます。
</para>
<para>
<!--O
The defaults may be too big or too small, depending on the specific
combination of hardware and kernels. On the one hand, some combinations of
Linux kernels and network cards (largely on older machines) cannot handle
blocks that large. On the other hand, if they can handle larger blocks, a
bigger size might be faster.
-->
デフォルトの値は大きすぎ/小さすぎかもしれません。
全ての、あるいは大抵の設定に有効なサイズ、というものはありません。
例えば Linux カーネルとネットワークカードの組み合わせ
(ほとんどは古いマシンでの話) によっては、あまり大きなブロックは扱えません。
一方大きなブロックが扱えれば、大きなサイズの転送は高速になります。
</para>
<para>
<!--O
You will want to experiment and find an <userinput>rsize</userinput>
and <userinput>wsize</userinput> that works and is as
fast as possible. You can test the speed of your options with some simple
commands, if your network environment is not heavily used. Note that your
results may vary widely unless you resort to using more complex benchmarks,
such as <application>Bonnie</application>, <application>Bonnie++</application>,
or <application>IOzone</application>.
-->
実験を行って、動作する限りで最速となるような
<userinput>rsize</userinput> や <userinput>wsize</userinput>
を決定しましょう。ある設定にしたときの転送速度は、
ネットワークが混雑していなければ、
いくつかの簡単なコマンドで調べられます。
実際の結果は場合によって大きく変わってしまうかもしれません。
その際には
<application>Bonnie</application>, <application>Bonnie++</application>,
<application>IOzone</application> といった、
より複雑なベンチマークを使うことになります。
</para>
<para>
<!--O
The first of these commands transfers 16384 blocks of 16k each from the
special file <filename>/dev/zero</filename> (which if 
you read it just spits out zeros <emphasis>really</emphasis>
fast) to the mounted partition. We will time it to see how long it takes. So,
from the client machine, type:
-->
最初に実行すべきコマンドは、16k のブロック 16384 個を、
特殊なファイル <filename>/dev/zero</filename>
(読み込むと 0 を「非常に」高速に吐き出してきます)
からマウントしたパーティションに転送するものです。
どのくらい時間がかかるかは time で測りましょう。
クライアントマシンから次のように入力します。
</para>
<programlisting>
    # time dd if=/dev/zero of=/mnt/home/testfile bs=16k count=16384
</programlisting>
<para>
<!--O
This creates a 256Mb file of zeroed bytes. In general, you should create a
file that's at least twice as large as the system RAM on the server, but make
sure you have enough disk space! Then read back the file into the great black
hole on the client machine (<filename>/dev/null</filename>) by 
typing the following:
-->
こうすると (バイトデータの) 0 で埋めつくされた、
大きさが 256Mb のファイルができます。
一般には、サーバに積んである RAM のサイズの、
少なくとも 2 倍の大きさのファイルを作るべきです
(ただしディスクに空きがあるか、確認を忘れないこと!)。
次にそのファイルを、クライアントのブラックホール
(<filename>/dev/null</filename>) に読み出します。
次のように入力してください。
</para>
<programlisting>
    # time dd if=/mnt/home/testfile of=/dev/null bs=16k
</programlisting>
<para>
<!--O
Repeat this a few times and average how long it takes. Be sure to unmount and
remount the filesystem each time (both on the client and, if you are zealous,
locally on the server as well), which should clear out any caches.
-->
これを何回か繰り返して、かかった時間を平均してください。
対象のファイルシステムを毎回アンマウント→再マウントして
(クライアントと、こだわる方はサーバでも)、
キャッシュの効果をすべてクリアするのを忘れずに。
</para>
<para>
<!--O
Then unmount, and mount again with a larger and smaller block size. They
should be multiples of 1024, and not larger than the maximum block size
allowed by your system. Note that NFS Version 2 is limited to a maximum of 8K,
regardless of the maximum block size defined by 
<userinput>NFSSVC_MAXBLKSIZE</userinput>; Version 3
will support up to 64K, if permitted. The block size should be a power of two
since most of the parameters that would constrain it (such as file system
block sizes and network packet size) are also powers of two. However, some
users have reported better successes with block sizes that are not powers of
two but are still multiples of the file system block size and the network
packet size.
-->
終わったらアンマウントし、ブロックサイズを増減して
もう一度マウントしてください。サイズは 1024 の倍数にし、
またシステムでの最大ブロックサイズは越えないようにしましょう。
NFS Version 2 の最大サイズは、
<userinput>NFSSVC_MAXBLKSIZE</userinput> での定義にかかわらず 8K です。
Version 3 は、許可されていれば 64K までサポートします。
ブロックサイズは 2 倍ずつ変えていくのが良いでしょう。
転送に関連するパラメータ (ファイルのシステムブロックサイズや
ネットワークのパケットサイズなど) も、
たいていは 2 倍ずつ変わるからです。
ただし、ブロックサイズを 2 の冪乗以外の値にして、
より良い結果を得たユーザもいます。
しかしその場合でも、システムのブロックサイズや
ネットワークパケットサイズの整数倍にはなっていました。
</para>
<para>
<!--O
Directly after mounting with a larger size, cd into the mounted
file system and do things like <command>ls</command>, explore 
the filesystem a bit to make sure everything is as it
should. If the <userinput>rsize</userinput>/<userinput>wsize</userinput>
 is too large the symptoms are very odd and not 100%
obvious. A typical symptom is incomplete file lists when doing 
<command>ls</command>, and no
error messages, or reading files failing mysteriously with no error messages.
After establishing that the given <userinput>rsize</userinput>/
<userinput>wsize</userinput> works you can do the speed tests
again. Different server platforms are likely to have different optimal sizes.
-->
大きなサイズでマウントしたら、
そのファイルシステムに cd し、<command>ls</command> するなどして、
ファイルシステムの中味が正しく見えるか調べてみて下さい。
<userinput>rsize</userinput> や <userinput>wsize</userinput>
が大き過ぎると、妙な兆候が現われ、
ファイルの信頼性が 100&percnt; でなくなります。
よくある例としては
「<command>ls</command> してもすべてが表示されない、
エラーメッセージも出ない」とか
「エラーメッセージは出ないのにファイルの読み込みになぜか失敗する」
などがあります。
さて、与えた <userinput>rsize</userinput>/<userinput>wsize</userinput>
でシステムが正しく動作していることがわかったら、
もう一度速度のテストをしてみましょう。
サーバの OS が違うと最適なサイズも異なる場合が多いです。
</para>
<para>
<!--O
Remember to edit <filename>/etc/fstab</filename> to reflect the 
<userinput>rsize</userinput>/<userinput>wsize</userinput> you found
to be the most desirable.
-->
最後に <filename>/etc/fstab</filename> を編集して、
決まった <userinput>rsize</userinput>/<userinput>wsize</userinput>
の値を反映させるのを忘れないように。
</para>
<para>
<!--O
If your results seem inconsistent, or doubtful, you may need to analyze your
network more extensively while varying the <userinput>rsize</userinput>
and <userinput>wsize</userinput> values. In that
case, here are several pointers to benchmarks that may prove useful:
-->
結果が一貫しなかったり、疑わしかったりした場合には、
<userinput>rsize</userinput> や <userinput>wsize</userinput>
の値を変化させながら、
ネットワークをもっと真面目に解析する必要があるかもしれません。
その場合には、ベンチマークソフトを使うと良いかもしれません。
いくつかポインタを挙げておきます。
</para>
<itemizedlist>
<listitem>
<para>
     Bonnie                            <ulink
url="http://www.textuality.com/bonnie/">http://www.textuality.com/bonnie/</ulink>
</para>
</listitem>
<listitem>
<para>
     Bonnie++                          <ulink
url="http://www.coker.com.au/bonnie++/">http://www.coker.com.au/bonnie++/</ulink>
</para>
</listitem>
<listitem>
<para>
     IOzone file system benchmark      <ulink url="http://www.iozone.org/">http://www.iozone.org/</ulink>
</para>
</listitem>
<listitem>
<para>
<!--O
     The official NFS benchmark,
-->
     公式の NFS ベンチマーク,
     SPECsfs97                         <ulink url="http://www.spec.org/osg/sfs97/">http://www.spec.org/osg/sfs97/</ulink>
</para>
</listitem>
</itemizedlist>
<para>
<!--O
The easiest benchmark with the widest coverage, including an extensive spread
of file sizes, and of IO types - reads, & writes, rereads & rewrites, random
access, etc. - seems to be IOzone. A recommended invocation of IOzone (for
which you must have root privileges) includes unmounting and remounting the
directory under test, in order to clear out the caches between tests, and
including the file close time in the measurements. Assuming you've already
exported <filename>/tmp</filename> to everyone from the server
<computeroutput>foo</computeroutput>, 
and that you've installed IOzone in the local directory, this should work:
-->
非常にさまざまなファイルサイズや、
さまざまな IO 形式
(読み出し・書き込み、再読み出し・再書き込み、ランダムアクセスなどなど)
など、最も広い範囲を扱えて、かつ最も簡単なベンチマークは、
IOzone のように思います。
推奨される IOzone の実行方法としては (これには root 権限が必要ですが)、
テストするディレクトリをアンマウント・再マウントして
キャッシュが関与しないようにし、
ファイルクローズ時間の測定をテストに入れるようなやり方です。
すでにサーバ <computeroutput>foo</computeroutput> で
<filename>/tmp</filename> を制限なしでエクスポートしており、
IOzone をローカルディレクトリにインストール済みであるとすると、
次のようなコマンド群になります。
</para>
<programlisting>
    # echo "foo:/tmp /mnt/foo nfs rw,hard,intr,rsize=8192,wsize=8192 0 0"
    >> /etc/fstab
    # mkdir /mnt/foo
    # mount /mnt/foo
    # ./iozone -a -R -c -U /mnt/foo -f /mnt/foo/testfile > logfile
</programlisting>
<para>
<!--O
The benchmark should take 2-3 hours at most, but of course you will need to
run it for each value of rsize and wsize that is of interest. The web site
gives full documentation of the parameters, but the specific options used
above are:
-->
ベンチマークには最大で 2〜3 時間かかります。
そして、もちろん対象の <userinput>rsize</userinput> や
<userinput>wsize</userinput> を変更するたびに実行する必要があります。
web サイトにはパラメータを網羅した文書がありますが、
上記で用いたオプションについては以下で説明します。
<itemizedlist>
<listitem>
<para>
<!--O
     <userinput>-a</userinput> Full automatic mode, which tests file sizes of 64K to 512M, using
     record sizes of 4K to 16M
-->
     <userinput>-a</userinput> 完全自動モード。
     ファイルサイズ 64K から 512M までを、
     レコードサイズ 4K から 16M まででテストします。
</para>
</listitem>
<listitem>
<para>
<!--O
     <userinput>-R</userinput> Generate report in excel spreadsheet form (The "surface plot"
     option for graphs is best)
-->
     <userinput>-R</userinput> レポートを
     Excel のスプレッドシートで生成します
     (グラフには "surface plot" オプションを用いるのが良いでしょう)。
<!--nakano TODO 日本語だと?-->
</para>
</listitem>
<listitem>
<para>
<!--O
     <userinput>-c</userinput> Include the file close time in the tests, which will pick up the
     NFS version 3 commit time
-->
     <userinput>-c</userinput> ファイルクローズ時間のテストを行う。
     これは NFS version 3 の commit 時間を取得します。
</para>
</listitem>
<listitem>
<para>
<!--O
     <userinput>-U</userinput> Use the given mount point to unmount and remount between tests;
     it clears out caches
-->
     <userinput>-U</userinput> 与えられたマウントポイントを
    テストごとにアンマウント/再マウントし、キャッシュをクリアする。
</para>
</listitem>
<listitem>
<para>
<!--O
     <userinput>-f</userinput> When using unmount, you have to locate the test file in the
     mounted file system
-->
     <userinput>-f</userinput> アンマウントを用いるときは、
     マウントされたファイルシステムに置かれた
     テストファイルを指定する必要があります。
</para>
</listitem>
</itemizedlist>
</sect2>
<sect2 id="packet-and-network">
<!--O
 <title>Packet Size and Network Drivers</title>
-->
 <title>パケットサイズとネットワークドライバ</title>
 <para>
<!--O
  While many Linux network card drivers are excellent, some are quite shoddy,
  including a few drivers for some fairly standard cards.  It is worth
  experimenting with your network card directly to find out how it can
  best handle traffic.
-->
  Linux のネットワークカードドライバの多くは優れたものですが、
  中には、比較的標準的なカードのものも含め、
  極めて出来の悪いものもあります。
  自分のネットワークカードを直接テストして、
  最高の状態で動作させるにはどうすれば良いかを知っておくのは、
  やるだけの価値があることだと言えます。
</para>
<para>
<!--O
   Try <command>ping</command>ing back and forth 
   between the two machines with large packets using
   the <userinput>-f</userinput> and <userinput>-s</userinput>
   options with <command>ping</command> (see <emphasis>ping(8)</emphasis> 
   for more details) and see if a
   lot of packets get dropped, or if they take a long time for a reply. If so,
   you may have a problem with the performance of your network card.
-->
   2 台のマシンの間で <command>ping</command> をやり取りしてみましょう。
   その際 <option>-f</option> オプションと
   <option>-s</option> オプションを用いて
   (詳細は <emphasis>ping(8)</emphasis> を見てください)
   大きなパケットを使い、
   大量のパケットロスが起きていないか、
   応答に時間がかかっていないかを見てみましょう。
   このような障害が起きている場合は、
   ネットワークカードの性能に問題があるかと思われます。
</para>
<para>
<!--O
For a more extensive analysis of NFS behavior in particular, use the <command>
nfsstat</command> command to look at nfs transactions, client and server statistics, network
statistics, and so forth. The <userinput>"-o net"</userinput> option will show you the number of
dropped packets in relation to the total number of transactions. In UDP
transactions, the most important statistic is the number of retransmissions,
due to dropped packets, socket buffer overflows, general server congestion,
timeouts, etc. This will have a tremendously important effect on NFS
performance, and should be carefully monitored. 
Note that <command>nfsstat</command> does not yet
implement the <userinput>-z</userinput> option, which would zero out all counters, so you must look
at the current <command>nfsstat</command> counter values prior to running the benchmarks.
-->
NFS の動作に特化した解析をより詳しく行うには、
<command>nfsstat</command> コマンドをつかって
NFS トランザクション、クライアント/サーバの統計、
ネットワークの統計などを見てください。
<userinput>"-o net"</userinput> オプションを用いると、
トランザクションの総パケット数に対するパケット落ちの回数が表示されます。
UDP トランザクションで最も重要な統計は再送数で、
これはパケット落ち、ソケットのバッファオーバーフロー、
一般的なサーバの過負荷、タイムアウトなどによって生じます。
これは NFS の性能に非常に重要な影響を与えるので、
注意深く見る必要があります。
なお <command>nfsstat</command> はまだ
カウンタをゼロにリセットする
<userinput>-z</userinput> オプションを実装していません。
したがって、ベンチマークを行う前に、まず
<command>nfsstat</command> カウンタの現在値を見ておく必要があります。
</para>
<para>
<!--O
To correct network problems, you may wish to reconfigure the packet size that
your network card uses. Very often there is a constraint somewhere else in the
network (such as a router) that causes a smaller maximum packet size between
two machines than what the network cards on the machines are actually capable
of. TCP should autodiscover the appropriate packet size for a network, but UDP
will simply stay at a default value. So determining the appropriate packet
size is especially important if you are using NFS over UDP.
-->
ネットワークの問題を修正するには、
ネットワークカードの用いているパケットサイズを再設定するといいでしょう。
2 台のマシンの間でやり取りできるパケットサイズの最大値は、
ほとんどの場合ネットワークのどこか (例えばルータ) において、
ネットワークカードのものより小さな値に制限されています。
TCP ではネットワークに対して適切なパケットサイズを
自動的に見つけるようになっていますが、
UDP では単にデフォルトの値を使うだけです。
従って、特に UDP 上で NFS を使っている場合には、
適切なパケットサイズを決めることは非常に重要です。
</para>
<para>
<!--O
You can test for the network packet size using the <command>tracepath</command> command: From
the client machine, just type <userinput>tracepath</userinput> 
<emphasis>server</emphasis> <userinput>2049</userinput> and the path MTU should
be reported at the bottom. You can then set the MTU on your network card equal
to the path MTU, by using the <userinput>MTU</userinput> 
option to <command>ifconfig</command>, and see if fewer packets
get dropped. See the <command>ifconfig</command> man pages for details on how to reset the MTU.
-->
ネットワークパケットサイズのテストは
<command>tracepath</command> コマンドによって行えます。
クライアントマシンから単に
<userinput>tracepath</userinput> <emphasis>server</emphasis> <userinput>2049</userinput>
と入力すれば、末尾に path MTU が表示されます。
次に <command>ifconfig</command> の MTU オプションを使って、
ネットワークカードの MTU を path MTU の値と同じにし、
パケット落ちが少なくなるか確認してください。
MTU の再設定方法の詳細は <command>ifconfig</command> の
man ページを見てください。
</para>
<para>
<!--O
In addition, <command>netstat -s</command> will give the statistics collected for traffic across
all supported protocols. You may also look at 
<filename>/proc/net/snmp</filename> for information
about current network behavior; see the next section for more details.
-->
さらに <command>netstat -s</command> を使えば、
サポートされているプロトコル全てに対して収集された統計が表示されます。
また <filename>/proc/net/snmp</filename> を見れば、
現在のネットワークの動作状況に関する情報がわかります。
詳細は次の節を見てください。
</para>
</sect2>
<sect2 id="frag-overflow">
<!--O
 <title>Overflow of Fragmented Packets</title>
-->
 <title>フラグメントされたパケットのオーバーフロー</title>
 <para>
<!--O
Using an <userinput>rsize</userinput> or <userinput>wsize</userinput> 
larger than your network's MTU (often set to 1500, in
many networks) will cause IP packet fragmentation when using NFS over UDP. IP
packet fragmentation and reassembly require a significant amount of CPU
resource at both ends of a network connection. In addition, packet
fragmentation also exposes your network traffic to greater unreliability,
since a complete RPC request must be retransmitted if a UDP packet fragment is
dropped for any reason. Any increase of RPC retransmissions, along with the
possibility of increased timeouts, are the single worst impediment to
performance for NFS over UDP.
-->
network の MTU (多くのネットワークでは通常 1500)
よりも大きな <userinput>rsize</userinput> や <userinput>wsize</userinput> 
を用いると、NFS over UDP を使っている場合には
IP パケットはフラグメント化されます。
IP パケットのフラグメント化と再構成は、
ネットワーク接続の両側で、相当量の CPU 資源を必要とします。
さらにパケットのフラグメント化が行われている状態では、
UDP パケットのフラグメントがなんらかの理由で落ちたときに
RPC リクエスト全体を再送しなければならないため、
ネットワーク転送をずっと不安定にします。
RPC 再送の増加は、タイムアウトを増加させることになりかねず、
NFS over UDP の性能を悪化させる最悪の原因となります。
</para>
<para>
<!--O
Packets may be dropped for many reasons. If your network topography is
complex, fragment routes may differ, and may not all arrive at the Server for
reassembly. NFS Server capacity may also be an issue, since the kernel has a
limit of how many fragments it can buffer before it starts throwing away
packets. With kernels that support the <filename>/proc</filename> 
filesystem, you can monitor the
files <filename>/proc/sys/net/ipv4/ipfrag_high_thresh</filename> and
<filename>/proc/sys/net/ipv4/ipfrag_low_thresh</filename>. Once the number of unprocessed,
fragmented packets reaches the number specified by <filename>ipfrag_high_thresh</filename> (in
bytes), the kernel will simply start throwing away fragmented packets until
the number of incomplete packets reaches the number specified by
<filename>ipfrag_low_thresh.</filename>
-->
パケット落ちはいろいろな理由で生じます。
ネットワークの形状が複雑だと、フラグメントの経路が異なるかも知れず、
サーバでの再構成時に全てが到着しないかもしれません。
カーネルがバッファできるフラグメントの数には上限があり、
これを越えるとパケットは破棄されるため、
NFS サーバの収容能力も問題になります。
<filename>/proc</filename> ファイルシステムをサポートするカーネルでは、
<filename>/proc/sys/net/ipv4/ipfrag_high_thresh</filename> と
<filename>/proc/sys/net/ipv4/ipfrag_low_thresh</filename>
ファイルで確認できます。
未処理のフラグメント化パケットが
<filename>ipfrag_high_thresh</filename> (バイト単位)
を越えると、カーネルは単純にパケットのフラグメントを捨てはじめ、
サイズの合計が <filename>ipfrag_low_thresh</filename>
に指定した値になるまで捨て続けます。
</para>
<para>
<!--O
Another counter to monitor is <userinput>IP: ReasmFails</userinput> 
in the file <filename>/proc/net/snmp</filename>; this
is the number of fragment reassembly failures. if it goes up too quickly
during heavy file activity, you may have problem.
-->
別のモニターカウンタとして、
<filename>/proc/net/snmp</filename> ファイルにある
<userinput>IP: ReasmFails</userinput> があります。
この数は、フラグメントの再構成に失敗した回数です。
重いファイル操作の際にこの値があまりに急激に上昇する場合は、
おそらく問題が生じています。
</para>
</sect2>
<sect2 id="nfs-tcp">
 <title>NFS over TCP</title>
 <para>
<!--O
A new feature, available for both 2.4 and 2.5 kernels but not yet
integrated into the mainstream kernel at the time of 
this writing, is NFS over TCP. Using TCP
has a distinct advantage and a distinct disadvantage over UDP.  The advantage
is that it works far better than UDP on lossy networks.
When using TCP, a single dropped packet can be retransmitted, without
the retransmission of the entire RPC request, resulting in better performance
on lossy networks. In addition, TCP will handle network speed differences
better than UDP, due to the underlying flow control at the network level. 
-->
新しい機能である NFS over TCP は、
2.4 カーネルでも 2.5 カーネルでも利用できますが、
まだ執筆時点ではメインストリームのカーネルには統合されていません。
TCP の利用には、UDP に対してはっきりした利点・欠点があります。
利点は、ロスの多いネットワークにおいて UDP よりずっと良く動作することです。
TCP を使った場合は、パケットがひとつ落ちると単にそれが再送され、
RPC リクエスト全体を再送するようなことは起こりません。
よってロスの多いネットワークではより良い性能を示します。
さらに TCP は、下層のネットワークレベルでのフロー制御のおかげで、
ネットワーク速度の違いを UDP よりもうまく扱えます。
</para>
<para>
<!--O
The disadvantage of using TCP is that it is not a stateless protocol like
UDP.  If your server crashes in the middle of a packet transmission,
the client will hang and any shares will need to be unmounted and remounted.
-->
TCP を用いることの欠点は、
TCP が UDP のようなステートレスのプロトコルではないことです。
パケット送信の最中にサーバがクラッシュすると、
クライアントはハングしてしまい、
すべての共有をアンマウント・再マウントする必要が生じます。
</para>
<para>
<!--O
The overhead incurred by the TCP protocol will result in
somewhat slower performance than UDP under ideal network
conditions, but the cost is not severe, and is often not
noticable without careful measurement. If you are using 
gigabit ethernet from end to end, you might also investigate the
usage of jumbo frames, since the high speed network may
allow the larger frame sizes without encountering increased 
collision rates, particularly if you have set the network 
to full duplex.
-->
TCP プロトコルはオーバーヘッドを必要とするため、
理想的なネットワーク環境の下では
UDP に比べて少々性能が低下します。
しかしそのコストはあまり厳しいものではなく、
注意深く測定しないと気付かない場合が多いでしょう。
通信の端から端まで gigabit イーサネットを使っているような場合は、
巨大なフレームの利用を試みてみるといいかもしれません。
高速なネットワークでは、特にネットワークが全二重の場合には、
フレームサイズを大きくしても衝突レートが増加しないからです。
</para>
</sect2>
<sect2 id="timeout">
<!--O
 <title>Timeout and Retransmission Values</title>
-->
 <title>タイムアウトと再送の値</title>
 <para>
<!--O
Two mount command options, <userinput>timeo</userinput> 
and <userinput>retrans</userinput>, control the behavior of UDP
requests when encountering client timeouts due to dropped packets, network
congestion, and so forth. The <userinput>-o timeo</userinput> 
option allows designation of the length
of time, in tenths of seconds, that the client will wait until it decides it
will not get a reply from the server, and must try to send the request again.
The default value is 7 tenths of a second. The 
<userinput>-o retrans</userinput> option allows
designation of the number of timeouts allowed before the client gives up, and
displays the <computeroutput>Server not responding</computeroutput> 
message. The default value is 3 attempts.
Once the client displays this message, it will continue to try to send
the request, but only once before displaying the error message if
another timeout occurs.  When the client reestablishes contact, it 
will fall back to using the correct <userinput>retrans</userinput> 
value, and will display the <computeroutput>Server OK</computeroutput> message.
-->
<command>mount</command> コマンドの 2 つのオプション、
<userinput>timeo</userinput> と <userinput>retrans</userinput> は、
クライアントがパケット落ち・ネットワーク負荷などによってタイムアウトしたときの、
UDP リクエストの動作を制御するものです。
<userinput>-o timeo</userinput>
オプションは時間の長さを 1/10 秒単位で指定するもので、
クライアントはこの時間を越えるとサーバから応答がもらえなかったと判断し、
リクエストを再送しようと試みます。
デフォルトは 0.7 秒です。
<userinput>-o retrans</userinput> オプションは、
クライアントがあきらめるまでに許されるタイムアウト回数で、
これを越えると <computeroutput>Server not responding</computeroutput> 
というメッセージが表示されます。
デフォルトは 3 回です。
クライアントがこのメッセージを表示したら、
リクエストを送信しようとし続けますが、
次のタイムアウト 1 回で、エラーメッセージを表示します。
<!--nakaon でいいのかな -->
接続が復帰すると、クライアントはふたたび元の
<userinput>retrans</userinput> の値を用いるようになり、
<computeroutput>Server OK</computeroutput> というメッセージを表示します。
</para>
<para>
<!--O
If you are already encountering excessive retransmissions (see the output of
the <command>nfsstat</command> command), or want to increase the block transfer size without
encountering timeouts and retransmissions, you may want to adjust these
values. The specific adjustment will depend upon your environment, and in most
cases, the current defaults are appropriate.
-->
すでに大量の再送が起きていたり
(<command>nfsstat</command> コマンドの出力を見てください)、
あるいはタイムアウト・再送を引き起こすことなく
ブロック転送サイズを増加させたい場合には、
これらの値を調整するといいでしょう。
適切な調整値は環境に依存しますが、
ほとんどの場合では現在のデフォルトで問題ないはずです。
</para>
</sect2>
<sect2 id="nfsd-instance">
<!--O
 <title>Number of Instances of the NFSD Server Daemon</title>
-->
 <title>NFSD のインスタンスの数</title>
 <para>
<!--O
Most startup scripts, Linux and otherwise, start 8 instances of 
<command>nfsd</command>. In the
early days of NFS, Sun decided on this number as a rule of thumb, and everyone
else copied. There are no good measures of how many instances are optimal, but
a more heavily-trafficked server may require more. 
You should use at the very least one daemon per processor, but
four to eight per processor may be a better rule of thumb.
If you are using a 2.4 or
higher kernel and you want to see how heavily each 
<command>nfsd</command> thread is being used,
you can look at the file <filename>/proc/net/rpc/nfsd</filename>.
The last ten numbers on the <userinput>th</userinput>
line in that file indicate the number of seconds that the thread usage was at
that percentage of the maximum allowable. If you have a large number in the
top three deciles, you may wish to increase the number 
of <command>nfsd</command> instances. This
is done upon starting <command>nfsd</command> using the
number of instances as the command line
option, and is specified in the NFS startup script 
(<filename>/etc/rc.d/init.d/nfs</filename> on
Red Hat) as <userinput>RPCNFSDCOUNT</userinput>. 
See the <emphasis>nfsd(8)</emphasis> man page for more information.
-->
Linux でも他の OS でも、ほとんどの起動スクリプトでは、
<command>nfsd</command> のインスタンスを 8 つ起動します。
NFS の最初の頃に Sun はこの値を経験則として決め、
その後はみんなこの値をコピーしているのです。
どのくらいのプロセス数が最適かを決める良い基準はありませんが、
トラフィックの大きいサーバではより大きな値にするのが良いでしょう。
最低でもプロセッサ当たりひとつのデーモンは起動すべきで、
プロセッサ当たり 4 から 8 というのがだいたいの目安になるでしょう。
2.4 以降のカーネルを使っている人は、
各 <command>nfsd</command> スレッドがどのくらい使われているかを
<filename>/proc/net/rpc/nfsd</filename>
で見てみるといいでしょう。このファイルの
<emphasis>th</emphasis> 行の最後の 10 個の数字は、
割り当て可能な最大値に対する各パーセンテージに
そのスレッドがあった秒数を示しています。
最初の 3 つの値が大きいときは、
<command>nfsd</command> のインスタンスを増やすほうが良いでしょう。
これを行うには、<command>nfsd</command> を起動するときの
コマンドラインオプションでインスタンスの数を与えます。
NFS の起動スクリプト
(Red Hat なら <filename>/etc/rc.d/init.d/nfs</filename>) では
<userinput>RPCNFSDCOUNT</userinput> で指定します。
詳細は <emphasis>nfsd(8)</emphasis> の man ページを見てください。
</para>
</sect2>
<sect2 id="memlimits">
<!--O
 <title>Memory Limits on the Input Queue</title>
-->
 <title>入力キューのメモリ制限</title>
 <para>
<!--O
On 2.2 and 2.4 kernels, the socket input queue, where requests sit while they
are currently being processed, has a small default size limit (<filename>rmem_default</filename>)
of 64k. This queue is important for clients with heavy read loads, and servers
with heavy write loads. As an example, if you are running 8 instances of nfsd
on the server, each will only have 8k to store write requests while it
processes them. In addition, the socket output queue - important for clients
with heavy write loads and servers with heavy read loads - also has a small
default size (<filename>wmem_default</filename>).
-->
2.2 と 2.4 のカーネルでは、ソケットの入力キュー
(処理中のリクエストが待つところ) のデフォルトのサイズ制限値
(<filename>rmem_default</filename>) は小さく、64k しかありません。
このキューは読み込み負荷が大きいクライアントで、
また書き込み負荷の大きいサーバで重要です。
例えば、サーバで <command>nfsd</command> のインスタンスを
8 つ走らせているとすれば、
各々には処理対象のリクエストを保存する場所が 8k ずつしかないことになります。
さらに、ソケットの出力キュー
(書き込み負荷の大きなクライアント・読み込み負荷の大きなサーバで重要)
も、デフォルトのサイズ (<filename>wmem_default</filename>)
は小さくなっています。
</para>
<para>
<!--O
Several published runs of the NFS benchmark 
<ulink url="http://www.spec.org/osg/sfs97/">SPECsfs</ulink> 
specify usage of a much higher value for both
the read and write value sets, <filename>[rw]mem_default</filename> and 
<filename>[rw]mem_max</filename>. You might
consider increasing these values to at least 256k. The read and write limits
are set in the proc file system using (for example) the files
<filename>/proc/sys/net/core/rmem_default</filename> and 
<filename>/proc/sys/net/core/rmem_max</filename>. The
<filename>rmem_default</filename> value can be increased in three steps; the following method is a
bit of a hack but should work and should not cause any problems:
-->
NFS ベンチマーク
<ulink url="http://www.spec.org/osg/sfs97/">SPECsfs</ulink> 
の実行結果がいくつか公開されていますが、それらでは
<filename>[rw]mem_default</filename> と <filename>[rw]mem_max</filename>
の両方にずっと大きな値を指定しています。
これらの値は、少なくとも 256k にまで増やすことを考えるべきです。
読み書きの上限値は、(例えば) proc ファイルシステムの
<filename>/proc/sys/net/core/rmem_default</filename> と
<filename>/proc/sys/net/core/rmem_max</filename>
を用いて設定します。
<filename>rmem_default</filename> の値を増加させるには
3 つの段階を踏みます。以降に示す方法はちょっとあらっぽいですが、
ちゃんと動作しますし、問題を起こすこともないはずです。
</para>
<itemizedlist>
<listitem>
<para>
<!--O
     Increase the size listed in the file:
-->
    これらのファイルに書かれているサイズを増加します:
</para>
<programlisting>
     # echo 262144 > /proc/sys/net/core/rmem_default
     # echo 262144 > /proc/sys/net/core/rmem_max
</programlisting>
</listitem>
<listitem>
<para>
<!--O
     Restart NFS.  For example, on Red Hat systems,
-->
      NFS を再起動します。例えば RedHat システムなら次のようにします。
</para>
<programlisting>
     # /etc/rc.d/init.d/nfs restart
</programlisting>
</listitem>
<listitem>
<para>
<!--O
     You might return the size limits to their normal size in case other
     kernel systems depend on it:
-->
     サイズの上限値を通常の値に戻し、
     他のカーネルシステムはこちらを使うようにします。
</para>
<programlisting>
     # echo 65536 > /proc/sys/net/core/rmem_default
     # echo 65536 > /proc/sys/net/core/rmem_max
</programlisting>
</listitem>
</itemizedlist>
<para>
<!--O
     This last step may be necessary because machines have been reported to
     crash if these values are left changed for long periods of time.
-->
    この最後のステップは不可欠で、
    これらの値を長い間変えたままにしておくと、
    マシンがクラッシュするというレポートも受けています。
</para>
</sect2>
<sect2 id="autonegotiation">
<!--O
  <title>Turning Off Autonegotiation of NICs and Hubs</title>
-->
  <title>NIC とハブの自動ネゴシエーションを無効にする</title>
  <para>
<!--O
If network cards auto-negotiate badly with hubs and switches, and ports run at
different speeds, or with different duplex configurations, performance will be
severely impacted due to excessive collisions, dropped packets, etc. If you
see excessive numbers of dropped packets in the 
<command>nfsstat</command> output, or poor
network performance in general, try playing around with the network speed and
duplex settings. If possible, concentrate on establishing a 100BaseT full
duplex subnet; the virtual elimination of collisions in full duplex will
remove the most severe performance inhibitor for NFS over UDP.  Be careful
when turning off autonegotiation on a card: The hub or switch that the card
is attached to will then resort to other mechanisms (such as parallel detection)
to determine the duplex settings, and some cards default to half duplex
because it is more likely to be supported by an old hub.  The best solution, 
if the driver supports it, is to force the card to negotiate 100BaseT 
full duplex.
-->
ネットワークカードの中には、
動作速度や全二重・半二重が異なるハブ、スイッチ、ポートなどとの
自動ネゴシエーションがうまくできず、
大量のコリジョン・パケット落ちなどによって、
性能が非常に劣化するものがあります。
<command>nfsstat</command> の出力に大量のパケット落ちがあったり、
あるいは一般にネットワークの性能がでない場合は、
ネットワーク速度と全/半二重の設定をいじってみてください。
可能なら 100BaseT 全二重のサブネットを確立することに集中しましょう。
全二重による仮想的なコリジョン回避は、
NFS over UDP における最も大きな性能低下の原因を取り除いてくれるからです。
カードの自動ネゴシエーション機能を切るときには注意が必要です。
カードが接続されているハブやスイッチは、
別の方法で (例えば並列検知など) をもちいて全/半二重の設定を決めますが、
カードによっては
(古いハブでもサポートされているという理由から)
デフォルトが半二重になっていることがあるからです。
ドライバがサポートしているのであれば、
100BaseT 全二重でネゴシエーションするようカードに強制するのが最善です。
</para>
</sect2>
<!--HERE GOES-->
<sect2 id="sync-async">
<!--O
 <title>Synchronous vs. Asynchronous Behavior in NFS</title>
-->
 <title>NFS の同期動作と非同期動作</title>
 <para>
<!--O
The default export behavior for both NFS Version 2 and Version 3 protocols,
used by <command>exportfs</command> in <application>nfs-utils</application> 
versions prior to Version 1.11 (the latter is in the CVS tree, 
but not yet released in a package, as of January, 2002) is
"asynchronous". This default permits the server to reply to client requests as
soon as it has processed the request and handed it off to the local file
system, without waiting for the data to be written to stable storage. This is
indicated by the <userinput>async</userinput> option denoted in the server's export list. It yields
better performance at the cost of possible data corruption if the server
reboots while still holding unwritten data and/or metadata in its caches. This
possible data corruption is not detectable at the time of occurrence, since
the <userinput>async</userinput> option instructs the server to lie to the client, telling the
client that all data has indeed been written to the stable storage, regardless
of the protocol used.
-->
<application>nfs-utils</application> の Version 1.11 より前の
<command>exportfs</command> では、
NFS の Version 2 と Version 3 プロトコルのどちらにおいても、
デフォルトのエクスポートは「非同期 (asynchronous)」で行ないます
(なお Version 1.11 は CVS ツリーには存在しますが、
2002 年 1 月の段階ではまだパッケージになっていません)。
このデフォルトにおいては、サーバはクライアントからのリクエストに対し、
処理をローカルのファイルシステムに渡したところで返答することが許されており、
データが永続的なストレージに書き込まれることを待つ必要はありません。
これはサーバのエクスポートリストの
<userinput>async</userinput> オプションによって識別できます。
非同期動作は性能が向上しますが、
書き込んでいないデータやメタデータがキャッシュにあるときに
サーバがリブートすると、データが壊れる可能性があります。
このデータ破壊は実際に起こるまでわかりません。
<userinput>async</userinput> オプションを指定すると、
用いているプロトコルに関らず、
サーバはクライアントに対して、
データはすべて実際に永続的なストレージに書き込まれた、と嘘をつくからです。
</para>
<para>
<!--O
In order to conform with "synchronous" behavior, used as the default for most
proprietary systems supporting NFS (Solaris, HP-UX, RS/6000, etc.), and now
used as the default in the latest version of <command>exportfs</command>, the Linux Server's
file system must be exported with the <userinput>sync</userinput> option. Note that specifying
synchronous exports will result in no option being seen in the server's export
list:
-->
「同期 (synchronous)」動作は NFS をサポートする商用製品システム
(Solaris, HP-UX, RS/6000 など) の多くで、
また最新版の <command>exportfs</command> でもデフォルトになっています。
この動作をさせるには、Linux サーバのファイルシステムを
<userinput>sync</userinput> オプションでエクスポートする必要があります。
なお同期的なエクスポートをした場合は、
サーバのエクスポートリストにはオプションが表示されません。
</para>
<itemizedlist>
<listitem>
<para>
<!--O
     Export a couple file systems to everyone, using slightly different
     options:
-->
2 つのファイルシステムを、少々異なるオプションで、
あらゆるクライアントに対してエクスポートします。
</para>
<para>
<programlisting>
    # /usr/sbin/exportfs -o rw,sync *:/usr/local
    # /usr/sbin/exportfs -o rw *:/tmp
</programlisting>
</para>
</listitem>
<listitem>
<para>
<!--O
     Now we can see what the exported file system parameters look like:
-->
するとエクスポートされたファイルシステムのパラメータは
次のようになります。
</para>
<para>
<programlisting>
    # /usr/sbin/exportfs -v
    /usr/local *(rw)
    /tmp *(rw,async)
</programlisting>
</para>
</listitem>
</itemizedlist>
<para>
<!--O
If your kernel is compiled with the <filename>/proc</filename> filesystem,
then the file <filename>/proc/fs/nfs/exports</filename> will also show the
full list of export options.
-->
カーネルが <filename>/proc</filename> ファイルシステムをサポートするように
コンパイルされた場合は、
<filename>/proc/fs/nfs/exports</filename> ファイルによっても
すべてのエクスポートオプションのリストが表示できます。
</para>
<para>
<!--O
When synchronous behavior is specified, the server will not complete (that is,
reply to the client) an NFS version 2 protocol request until the local file
system has written all data/metadata to the disk. The server
<emphasis>will</emphasis> complete a
synchronous NFS version 3 request without this delay, and will return the
status of the data in order to inform the client as to what data should be
maintained in its caches, and what data is safe to discard. There are 3
possible status values, defined an enumerated type, <userinput>nfs3_stable_how</userinput>, in
<filename>include/linux/nfs.h</filename>. The values, along with the subsequent actions taken due
to these results, are as follows:
-->
同期動作を指定すると、サーバは NFS version 2 のリクエストに対して、
ローカルファイルシステムがすべてのデータ・メタデータをディスクに書き込むまで
動作を完了しません (つまりクライアントに応答しません)。
同期動作の NFS version 3 においては、
サーバはこの遅延を行うことなく返答を <emphasis>行い</emphasis>、
クライアントにデータの状態を返して、
どのデータをキャッシュに保持しておくべきか、
またどのデータは捨ててよいかを判断できるようにします。
<filename>include/linux/nfs.h</filename> の
enum 型変数 <userinput>nfs3_stable_how</userinput>
には、3 つの状態値があります。
</para>
<itemizedlist>
<listitem>
<para>
<!--O
NFS_UNSTABLE - Data/Metadata was not committed to stable storage on the
server, and must be cached on the client until a subsequent client commit
request assures that the server does send data to stable storage.
-->
NFS_UNSTABLE - データ・メタデータはサーバの永続的なストレージに
commit されていないので、
後でクライアントの commit リクエストによって
サーバが実際にデータを永続的なストレージに送ったことが確認できるまで、
クライアントでキャッシュしておかなければならない。
<!--nakano commit の訳語はどうしよう-->
</para>
</listitem>
<listitem>
<para>
<!--O
NFS_DATA_SYNC - Metadata was not sent to stable storage, and must be cached
on the client. A subsequent commit is necessary, as is required above.
-->
NFS_DATA_SYNC - メタデータは永続的なストレージに送られていないので、
クライアントでキャッシュしておかなければならない。
上の場合と同じように、後で commit を行う必要がある。
</para>
</listitem>
<listitem>
<para>
<!--O
NFS_FILE_SYNC - No data/metadata need be cached, and a subsequent commit
need not be sent for the range covered by this request.
-->
NFS_FILE_SYNC - データ・メタデータをキャッシュしておく必要はない。
また、このリクエストの範囲に対しては、後で commit を送る必要もない。
</para>
</listitem>
</itemizedlist>
<para>
<!--O
In addition to the above definition of synchronous behavior, the client may
explicitly insist on total synchronous behavior, regardless of the protocol,
by opening all files with the <userinput>O_SYNC</userinput> option. In this case, all replies to
client requests will wait until the data has hit the server's disk, regardless
of the protocol used (meaning that, in NFS version 3, all requests will be
<userinput>NFS_FILE_SYNC</userinput> requests, and will require that the Server returns this status).
In that case, the performance of NFS Version 2 and NFS Version 3 will be
virtually identical.
-->
上記の同期動作の定義に加え、
クライアントから (プロトコルによらず)
明示的に完全な同期動作を行うような指定もできます。
これにはファイルをオープンする際に <userinput>O_SYNC</userinput>
オプションを指定します。
この場合、クライアントからのリクエストに対する応答は、
データが実際にサーバのディスクに書き込まれるまで行なわれません。
これはプロトコルによりません
(つまり NFS version 3 に対しては、
すべてのリクエストが <userinput>NFS_FILE_SYNC</userinput> リクエストとなり、
これはサーバに対して必ずこの状態を返すように求めるのです)。
この場合、NFS version 2 と NFS version 3 の性能は事実上同じになります。
</para>
<para>
<!--O
If, however, the old default <userinput>async</userinput> 
behavior is used, the <userinput>O_SYNC</userinput> option has
no effect at all in either version of NFS, since the server will reply to the
client without waiting for the write to complete. In that case the performance
differences between versions will also disappear.
-->
しかし、古いデフォルトである
<userinput>async</userinput> 動作が用いられていた場合には、
いずれの NFS バージョンにおいても
<userinput>O_SYNC</userinput> オプションは全く意味を持ちません。
サーバは書き込みの完了を待つことなくクライアントに応答してしまうからです。
この場合も、バージョンの違いによる性能差は現われません。
</para>
<para>
<!--O
Finally, note that, for NFS version 3 protocol requests, a subsequent commit
request from the NFS client at file close time, or at <command>fsync()</command> time, will force
the server to write any previously unwritten data/metadata to the disk, and
the server will not reply to the client until this has been completed, as long
as <userinput>sync</userinput> behavior is followed. If <userinput>async</userinput> is used, the commit is essentially
a no-op, since the server once again lies to the client, telling the client that
the data has been sent to stable storage. This again exposes the client and
server to data corruption, since cached data may be discarded on the client
due to its belief that the server now has the data maintained in stable
storage.
-->
最後に一言。NFS version 3 プロトコルのリクエストでは、
ファイルをクローズするときや <command>fsync()</command> の時に
NFS クライアントから「後出し」の commit リクエストが発行されますが、
これによってサーバは以前書き込みを完了していなかった
データ・メタデータをディスクに書き込むよう強制されます。
そしてサーバは、
<userinput>sync</userinput> 動作に従うのであれば、
この書き込みが終了するまでクライアントに応答しません。
一方もし <userinput>async</userinput> が用いられている場合は、
commit は基本的に no-op (何も行なわない動作) です。
なぜならサーバは再びクライアントに対して、
データは既に永続的なストレージに送られた、と嘘をつくからです。
するとクライアントはサーバがデータを永続的なストレージに保存したと信じて
自分のキャッシュを捨ててしまうので、
これはやはりクライアントとサーバをデータ破壊の危険に晒すことになります。
</para>
</sect2>
<sect2 id="non-nfs-performance">
<!--O
 <title>Non-NFS-Related Means of Enhancing Server Performance</title>
-->
 <title>サーバの性能をあげる NFS 以外の方法</title>
  <para>
<!--O
In general, server performance and server disk access speed will have an
important effect on NFS performance.
Offering general guidelines for setting up a well-functioning file server is
outside the scope of this document, but a few hints may be worth mentioning:
-->
一般に、サーバの性能とサーバのディスクアクセス速度は
NFS の性能にも重要な影響を及ぼします。
良好に機能するファイルサーバの設定に対するガイドラインを提供することは、
この文書で扱う範囲を越えていますが、
いくつかのヒントを提供しておく価値はあるでしょう。
</para>
<itemizedlist>
<listitem>
<para>
<!--O
If you have access to RAID arrays, use RAID 1/0 for both write speed and
redundancy; RAID 5 gives you good read speeds but lousy write speeds.
-->
RAID アレイを利用できる場合は、
RAID 1/0 を用いて書き込み速度と冗長度の両方を確保しましょう。
RAID 5 を用いると読み込みは速くなりますが、
書き込みはみじめなことになります。
</para>
</listitem>
<listitem>
<para>
<!--O
A journalling filesystem will drastically reduce your reboot time in the
event of a system crash. Currently,
<ulink url="ftp://ftp.uk.linux.org/pub/linux/sct/fs/jfs/">ext3
</ulink> will work correctly with NFS
version 3. In addition, Reiserfs version 3.6 will work with NFS version 3 on
2.4.7 or later kernels (patches are available for previous kernels). Earlier versions
of Reiserfs did not include room for generation numbers in the inode, exposing
the possibility of undetected data corruption during a server reboot.
-->
ジャーナリングファイルシステムを用いれば、
システムがクラッシュしたときに再起動に要する時間が劇的に短くなります。
現時点では、
<ulink url="ftp://ftp.uk.linux.org/pub/linux/sct/fs/jfs/">ext3</ulink>
が NFS version 3 と一緒に正しく動作します。
また Reiserfs version 3.6 以降も、
2.4.7 以降のカーネルの NFS version 3 と一緒に正しく動作します
(それ以前のカーネルに対するパッチもあります)。
それより前の Reiserfs では、生成番号 (generation number)
の保管場所が inode に無いため、
サーバが再起動したときに検知不可能な形でデータが破壊する可能性があります。
</para>
</listitem>
<listitem>
<para>
<!--O
Additionally, journalled file systems can be configured to maximize
performance by taking advantage of the fact that journal updates are all that
is necessary for data protection. One example is using ext3 with <userinput>data=journal</userinput>
so that all updates go first to the journal, and later to the main file
system. Once the journal has been updated, the NFS server can safely issue the
reply to the clients, and the main file system update can occur at the
server's leisure.
-->
また、ジャーナリングファイルシステムにおいて、
ジャーナルの更新はデータ保護のためにのみ必要である、
という事実を利用すれば、性能を最大化することが可能です。
例えば ext3 を例に取るなら、
<userinput>data=journal</userinput> を用いて、
更新をまずすべてジャーナルに対して行ない、
そしてその後でファイルシステム本体に対して行うようにします。
ジャーナルが更新されたら、
NFS サーバは安心してクライアントに対する応答を発行でき、
メインファイルシステムの更新はサーバが暇なときに行なえば良いのです。
</para>
<para>
<!--O
The journal in a journalling file system may also reside on a separate device
such as a flash memory card so that journal updates normally require no seeking. With only rotational
delay imposing a cost, this gives reasonably good synchronous IO performance.
Note that ext3 currently supports journal relocation, and ReiserFS will
(officially) support it soon. The Reiserfs tool package found at <ulink
url="ftp://ftp.namesys.com/pub/reiserfsprogs/reiserfsprogs-3.x.0k.tar.gz">
ftp://ftp.namesys.com/pub/reiserfsprogs/reiserfsprogs-3.x.0k.tar.gz </ulink>
contains
the <command>reiserfstune</command> tool, which will allow journal relocation. It does, however,
require a kernel patch which has not yet been officially released as of
January, 2002.</para>
-->
ジャーナリングファイルシステムのジャーナルを
フラッシュメモリカードなどの別のデバイスに置き、
ジャーナルの更新時にシーク動作を不要にすることもできます。
<!--nakano フラッシュメモリの rotational delay ってなんだ?-->
こうすれば回転待ちだけがコストになるので、
同期 IO の性能をかなり良くできます。
いまでは ext3 はジャーナルのリロケーションをサポートしており、
また ReiserFS も近々 (公式に) サポートするはずです。
<ulink url="ftp://ftp.namesys.com/pub/reiserfsprogs/reiserfsprogs-3.x.0k.tar.gz">ftp://ftp.namesys.com/pub/reiserfsprogs/reiserfsprogs-3.x.0k.tar.gz </ulink>
にある ReiserFS 用のツールパッケージには、
<command>reiserfstune</command> というツールがあり、
これを用いるとジャーナルのリロケーションを行なえます。
しかしこれにはカーネルパッチが必要で、
これはまだ 2002 年 1 月の段階では公式にはリリースされていません。
</listitem>
<listitem>
<para>
<!--O
Using an automounter (such as <application>autofs</application> or <application>amd</application>) may prevent hangs if you
cross-mount files on your machines (whether on purpose or by oversight) and
one of those machines goes down. See the <ulink url="http://www.linuxdoc.org/HOWTO/mini/Automount.html">Automount Mini-HOWTO</ulink> for details.
-->
automounter (<application>autofs</application> や
<application>amd</application>)  を用いれば、
クロスマウントを (わざとでもうっかりでも) したマシンの
どちらかが落ちたときでも、もう片方のハングアップを避けられます。
詳細は
<ulink url="http://www.linuxdoc.org/HOWTO/mini/Automount.html">Automount Mini-HOWTO</ulink>
を見てください
(JF に
<ulink url="http://www.linux.or.jp/JF/JFdocs/Automount.html">日本語訳</ulink>
があります)。
</para>
</listitem>
<listitem>
<para>
<!--O
Some manufacturers (Network Appliance, Hewlett Packard, and others) provide NFS
accelerators in the form of Non-Volatile RAM. NVRAM will boost access speed to
stable storage up to the equivalent of <userinput>async</userinput> access.
-->
メーカーによっては、不揮発 RAM (NVRAM) を用いた
NFS アクセレレータを提供しています
(Network Appliance, Hewlett Packard など)。
NVRAM を用いれば、永続的なストレージへのアクセスが
<userinput>async</userinput> 利用時と同じくらいにまで加速できます。
</para>
</listitem>
</itemizedlist>
</sect2>
</sect1>
