<!-- $Id: nfs.sgml,v 1.1.1.1 1996/11/15 05:14:39 asami Exp $ -->
<!-- The FreeBSD Japanese Documentation Project -->
<!-- Original revision: 1.7 -->

<sect><heading>NFS<label id="nfs"></heading>

<p><em>原作: &a.jlind;.</em>
<p><em>訳: &a.tomo;.<newline>6 September 1996.</em>

ISA用のイーサネットアダプタの中には性能が悪いため, ネットワーク, 
特に NFS で深刻な問題がおきるものがあります. これは FreeBSD に限ったことでは
ありませんが, FreeBSD でも起こり得ます. 

この問題は, (FreeBSDを使用した)PCがシリコン・グラフィックス社やサン・マイクロ
システムズ社などの高性能なWSにネットワーク接続されている場合に頻繁に
起こります. NFSマウントはうまく行きます. また, いくつかの操作もうまく
働きますが, 他のシステム(WS)に対する要求や応答は続いていても, 突然サーバ
がクライアントの要求に対して反応しなくなります. 
これは, クライアントがFreeBSDか上記のWSであるとき, にクライアント側に起きる
現象です. 多くのシステムでは, いったんこの問題が起きたら解決できないので, 
行儀よくシャットダウンするしかありません. 
唯一の解決策は, この状況に陥る前にクライアントをリセットすることです. 
なぜなら, 一旦この状況に陥ると NFS を解除することさえできないからです. 

"正しい"解決法は, より高性能のイーサネットアダプタをFreeBSDシステムに
インストールすることですが, 満足な操作ができるような簡単な方法があります. 
もし, FreeBSDシステムがサーバになるのなら, クライアントからのマウント時に
"-w=1024"オプションをつけて下さい. もしFreeBSDシステムがクライアントになる
のなら, NFSファイルシステムを"-r=1024"オプションつきでマウントして下さい. 
これらのオプションは自動的にマウントをおこなう場合には
クライアントのfstabエントリの4番目のフィールドに指定してもよいですし, 
手動マウントの場合はmountコマンドの"-o"パラメータで指定してもよいでしょう. 

NFSサーバとクライアントが別々のネットワーク上にあるような場合, 
これと間違えやすい他の問題が起きることに注意して下さい. そのような場合は, 
ルータが必要なUDP情報をきちんとルーティングしているかを確かめて下さい. 
そうでなければ, たとえあなたが何をしようと解決できないでしょう. 

次の例では, "fastws"は高性能のWSのホスト
(インタフェース)名で, "freebox"は低性能のイーサネットアダプタを備えた
FreeBSDシステムのホスト(インタフェース)名です. 

また, "/sharedfs"はエクスポートされるNFSファイルシステムであり
("man exports"を見て下さい), "/project"はエクスポートされたファイル
システムのクライアント上のマウントポイントとなります. 
全ての場合において, "hard"や"soft", "bg"といった追加オプションが
アプリケーションにより要求されるかもしれないことに注意して下さい. 

クライアント側FreeBSDシステム("freebox")の例は:
freeboxの<tt>/etc/fstab</tt>に次のように書いて下さい:
fastws:/sharedfs /project nfs rw,-r=1024 0 0
freebox上で手動でmountコマンドを実行する場合は次のようにして下さい:
mount -t nfs -o -r=1024 fastws:/sharedfs /project


サーバ側FreeBSDシステムの例は:
fastwsの<tt>/etc/fstab</tt>に次のように書いて下さい:
freebox:/sharedfs /project nfs rw,-w=1024 0 0
fastws上で手動でmountコマンドで実行する場合は次のようにして下さい:
mount -t nfs -o -w=1024 freebox:/sharedfs /project

近いうちにどのような16ビットのイーサネットアダプタでも上記の読み出し, 
書き込みサイズの制限なしの操作ができるようになるでしょう. 

失敗が発生したとき何が起きているか関心のある人に, なぜ回復不可能なのか
も含めて説明します. 
NFSは通常 (より小さいサイズへ分割されるかもしれませんが) 8Kの"ブロック"
サイズで働きます. イーサネットのパケットサイズは最大1500バイト程度なので, 
上位階層のコードにとっては1つのユニットのままなのですが, NFS"ブロック"は
複数のイーサネットパケットに分割されます. そして受信され, 組み立て直されてから
肯定応答されなければなりません. 高性能のWSは次々に
NFSユニットを構成するパケットを, 基準の範囲内で間隔を詰めて
次々に送り出すことができます. 小さく, 容量の低いカードでは, 同じユニットの
前のパケットがホストに転送される前に, 後のパケットがそれを
「踏みつぶし」てしまいます. このため全体としてのユニットは再構成もされないし, 
肯定応答もされません. その結果, WSはタイムアウトして再送を試みますが, 
8Kのユニット全体を再送しようとするので, このプロセスは
際限無く繰り返されてしまいます. 

ユニットサイズをイーサネットのパケットサイズの制限以下に抑えることにより, 
受信された完全なイーサネットパケットは個々に肯定応答を受けられることが
保証されるので, デッドロック状態を避けることができるようになります. 

高性能のカードを使っている場合でも, 高性能なWSが力任せに次々と
PCシステムにデータを送ったときには「踏みつぶし」が起きるかもしれません. 
そのような「踏みつぶし」はNFS"ユニット"では保証されていません. 
「踏みつぶし」が起こったとき, 影響を受けたユニットは再送されます. 
そして受信され, 組み立てられ, 肯定応答される公平な機会が与えられるでしょう.