21.4. NFS

21.4.1. どのようにして動作するのか

NFS はクライアント、 サーバの二つの部分から 構成されます。 これは 需要(want)/供給(have) の関係として考えることができます。 クライアントはサーバが 供給 している データに対する 需要 があります。 サーバはそのデータをクライアントと共有します。 このシステムが適切に機能するために、 いくつかのプロセスが 設定され正しく動作していなければなりません。

サーバは以下のデーモンを動作させなければなりません:

• nfsd - NFS クライアントからの リクエストを処理する NFS デーモン。

• mountd - nfsd から渡された リクエストを実際に実行する NFS マウントデーモン。

• portmap - NFS サーバの利用しているポートを NFS クライアントから取得できるようにするためのポートマッパデーモン。

クライアント側ではデーモンを一つ実行する必要があります:

• nfsiod - NFS サーバからのリクエストを 処理する NFS 非同期 I/O デーモン。

21.4.2. NFS を設定する

幸運なことに、 FreeBSD システムで設定を行うのは簡単です。 実行させなければならないプロセスは、 /etc/rc.conf ファイルをちょっと編集することでブート時から実行させる ことができます。

NFS サーバでは、 以下の設定が必要です:

portmap_enable="YES"
nfs_server_enable="YES"
nfs_server_flags="-u -t -n 4"
mountd_flags="-r"

mountd は NFS サーバが有効になっている 場合、 自動的に実行されます。 nfsd への -u、 -t フラグは クライアントに UDP と TCP のサービスを提供することを指示します。 -n 4 フラグは nfsd が 4 つのコピーを立ち上げることを指示します。

クライアント側では、 以下のようにします:

nfs_client_enable="YES"
nfs_client_flags="-n 4"

nfsd と同様に、 -n 4 は nfsiod が 4 つのコピーを立ち上げることを指示します。

最後に /etc/exports という 設定ファイルを作成します。 exports ファイルはサーバのどのファイルシステムが 共有されるのか (“exported” といいます)、 またどのクライアントが共有できるのかを指定します。 ファイル中の各行は、 共有されるファイルシステムを 指定します。 ファイル中で指定できるオプションはたくさんありますが、 そのうちの少ししか使うことはないでしょう。 より細かいことに関しては exports(5) マニュアルページをお読み下さい。

いくつか /etc/exports の設定例 を示します:

以下の設定は、 サーバと同じドメイン名(ドメイン名が無いので)か、 /etc/hosts に記述のある三つのマシン に対して、 /cdrom を export します。 -ro オプションは共有されるファイルシステムを 読み込み専用にします。 このフラグにより、 リモートシステムは共有されたファイルシステム にたいして何の変更も行えなくなります。

/cdrom -ro moe larry curly

以下の設定は、 IP アドレスによる三つのホストに対して /home を export します。 この設定はプライベートネットワークで DNS が走っていない 場合に便利な設定でしょう。 -alldirs フラグは指定されたファイルシステム 以下のディレクトリに対しても同様に export します。

/home  -alldirs  10.0.0.2 10.0.0.3 10.0.0.4

以下の設定は、 サーバとは異なるドメイン名の二つの マシンに対して /a を export します。 -maproot=0 フラグは、 リモートマシンの root ユーザが共有されたファイルシステムに root として書き込むことを 許可します。 -maproot=0 フラグが無ければ、 リモートマシンの root 権限を 持っていても共有されたファイルシステム上のファイルを変更する ことはできません。

/a  -maproot=0  host.domain.com box.example.com

クライアントが export されたファイルシステムを共有 する際には、 そのような権限が与えられていなければなりません。 /etc/exports ファイルに クライアントが含まれているかどうか確認してください。

必要な変更はすべて行ったので、 FreeBSD を再起動してブート時からすべてが起動するようにするか、 root で以下のコマンドを実行します:

NFS サーバでは:

# portmap
# nfsd -u -t -n 4
# mountd -r

NFS クライアントでは:

# nfsiod -n 4

これでリモートのファイルシステムを実際にマウントする 準備ができました。 やり方は二通りあります。 この例では、 サーバの名前は server で、 クライアントの名前は client とします。 リモートファイルシステムを一時的にマウントするだけ、 もしくは設定をテストするだけなら、 クライアント上で root として以下のコマンドを実行してください:

# mount server:/home /mnt

これにより、 クライアントの /mnt ディレクトリにサーバの /home が マウントされます。 もしすべてが正しく設定されていれば、 クライアントの /mnt に、 サーバにあるファイルすべてが見えるようになっているはずです。

リモートファイルシステムを今後も (リブートする度に) マウントしたいなら、 /etc/fstab ファイルに設定を追加する必要があります。 例としてはこのようになります:

server:/home   /mnt    nfs rw  0   0

ほかのオプションに関しては fstab(5) マニュアル ページをお読み下さい。

21.4.3. 典型的な使い方

NFS にはいくつかすてきな使い方があります。 私は自分が管理している LAN でそれらを利用しています。 そのうちにいくつかをここで紹介しましょう。

ネットワークには幾つかのマシンがありますが、 CD-ROM ドライブを持っているのは一台だけです。 なぜかって? それは一台の CD-ROM ドライブをほかのマシンと NFS 経由で共有しているからです。 フロッピードライブについても同じことがいえます。

ネットワーク内に多くのマシンがあると、 様々な場所に ちらばる個人的なファイルは日に日に古くなってしまいます。 私はすべてのユーザのホームディレクトリを格納する、 中心となる NFS サーバを用意し、 LAN 上の残りのマシンと 共有しています。 そうすることで、 どこにログインしても、 同じホームディレクトリを使うことができるのです。

マシンのひとつに FreeBSD を再インストールするなら、 NFS こそその方法です。 ディストリビューション CD をファイル サーバに入れ、 再インストールを実行するだけです。

共用の /usr/ports/distfiles ディレクトリを用意して、 すべてのマシンで共有しています。 この方法だと、 別のマシンで既にインストールしたことのある port をインストールする場合、 再びすべてのソースをダウンロードする 必要がなくなります。

21.4.4. Problems integrating with other systems

原作: John Lind <john@starfire.MN.ORG>.

訳: 渡辺 智雄 <tomo@jp.FreeBSD.org>. 6 September 1996.

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 の /etc/fstab に次のように書いて下さい:

fastws:/sharedfs /project nfs rw,-r=1024 0 0

freebox 上で手動で mount コマンドを実行する場合は次のようにして下さい:

# mount -t nfs -o -r=1024 fastws:/sharedfs /project

サーバ側FreeBSDシステムの例は: fastws の /etc/fstab に次のように書いて下さい:

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 “ユニット” では保証されていません。 踏みつぶしが起こったとき、 影響を受けたユニットは再送されます。 そして受信され、 組み立てられ、 肯定応答される公平な機会が与えられるでしょう。