diff options
Diffstat (limited to 'ja/handbook/nfs.sgml')
| -rw-r--r-- | ja/handbook/nfs.sgml | 88 |
1 files changed, 0 insertions, 88 deletions
diff --git a/ja/handbook/nfs.sgml b/ja/handbook/nfs.sgml deleted file mode 100644 index e55cc04d46..0000000000 --- a/ja/handbook/nfs.sgml +++ /dev/null @@ -1,88 +0,0 @@ -<!-- $Id: nfs.sgml,v 1.6 1997-02-25 04:57:11 hanai Exp $ --> -<!-- The FreeBSD Japanese Documentation Project --> -<!-- Original revision: 1.9 --> - -<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"ユニット"では保証されていません. -「踏みつぶし」が起こったとき, 影響を受けたユニットは再送されます. -そして受信され, 組み立てられ, 肯定応答される公平な機会が与えられるでしょう. |