4ae0a12bcb
Makefile yet as John needs to figure out ${LANG}-based doc building.
Please put this in 2.2, or the translators are going to kill me. ;)
Submitted by: doc-jp@jp.freebsd.org (The FreeBSD Japanese Doc Team)
Reviewed by: doc-jp@jp.freebsd.org (mutual review)
89 lines
4.4 KiB
Plaintext
89 lines
4.4 KiB
Plaintext
<!-- $Id$ -->
|
|
<!-- The FreeBSD Japanese Documentation Project -->
|
|
<!-- Original revision: 1.6 -->
|
|
|
|
<sect><heading>NFS<label id="nfs"></heading>
|
|
|
|
<p><em>原作: &a.john;.</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"ユニット"では保証されていません.
|
|
「踏みつぶし」が起こったとき, 影響を受けたユニットは再送されます.
|
|
そして受信され, 組み立てられ, 肯定応答される公平な機会が与えられるでしょう.
|