Finally, the Japanese version of the handbook. Not in the parent

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)

1 files changed, 88 insertions, 0 deletions

diff --git a/ja/handbook/nfs.sgml b/ja/handbook/nfs.sgml
new file mode 100644
index 0000000000..fcc73dd1f3
--- /dev/null
+++ b/ja/handbook/nfs.sgml
@@ -0,0 +1,88 @@
+<!-- $Id: nfs.sgml,v 1.1.1.1 1996-11-15 05:14:39 asami Exp $ -->
+<!-- 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"ユニット"では保証されていません. 
+「踏みつぶし」が起こったとき, 影響を受けたユニットは再送されます. 
+そして受信され, 組み立てられ, 肯定応答される公平な機会が与えられるでしょう.