FreeBSD がサポートしている多くのファイルシステムの中には、 NFS とも呼ばれているネットワークファイルシステムがあります。 NFS はあるマシンから他のマシンへと、 ネットワークを通じてディレクトリとファイルを共有することを可能にします。 NFS を使うことで、 ユーザやプログラムはリモートシステムのファイルを、 それがローカルファイルであるかのようにアクセスすることができます。
NFS が提供可能な最も特筆すべき利点いくつかは以下のものです。
一般的に使われるデータを単一のマシンに納めることができ、 ユーザはネットワークを通じてデータにアクセスできるため、 ローカルワークステーションが使用するディスク容量が減ります。
ネットワーク上のすべてのマシンに、 ユーザが別々にホームディレクトリを持つ必要がありません。 NFS サーバ上にホームディレクトリが設定されれば、 ネットワークのどこからでもアクセス可能です。
フロッピーディスクや CDROM ドライブ、 ZIP ドライブなどのストレージデバイスを、 ネットワーク上の他のマシンで利用することができます。 ネットワーク全体のリムーバブルドライブの数を減らせるかもしれません。
NFS は最低二つの主要な部分、 サーバと一つ以上のクライアントからなります。 クライアントはサーバマシン上に格納されたデータにリモートからアクセスします。 これが適切に機能するには、 いくつかのプロセスが設定されて実行されていなければなりません。
注意: FreeBSD 5.X では portmap ユーティリティは rpcbind ユーティリティに置き換わりました。 したがって FreeBSD 5.X では、ユーザは下記の例で、 portmap の例のすべてを rpcbind に置き換える必要があります。
サーバは以下のデーモンを動作させなければなりません。
| デーモン | 説明 |
|---|---|
| nfsd | NFS クライアントからのリクエストを処理する NFS デーモン |
| mountd | nfsd(8) から渡されたリクエストを実際に実行する NFS マウントデーモン |
| portmap | NFS サーバの利用しているポートを NFS クライアントから取得できるようにするためのポートマッパデーモン |
クライアント側では nfsiod というデーモンも実行できます。 nfsiod デーモンは NFS サーバからのリクエストを処理します。 これは任意であり、性能を改善しますが、 通常の正しい動作には必要としません。詳細については nfsiod(8) マニュアルページを参照してください。
NFS の設定は比較的素直な工程です。 動かさなければならないプロセスは /etc/rc.conf ファイルを少し変更すれば起動時に実行させられます。
NFS サーバでは /etc/rc.conf ファイルの中で、 以下のオプションが設定されていることを確かめてください。
portmap_enable="YES" nfs_server_enable="YES" mountd_flags="-r"
mountd は NFS サーバが有効になっていれば、 自動的に実行されます。
クライアント側では /etc/rc.conf 内に以下の設定があることを確認してください。
nfs_client_enable="YES"
/etc/exports ファイルは NFS サーバがどのファイルシステムをエクスポート (ときどき “共有” と呼ばれます) するのかを指定します。 /etc/exports ファイル中の各行は、 エクスポートするファイルシステム、 およびそのファイルシステムにアクセスできるマシンを指定します。 ファイルシステムにアクセスできるマシンとともに、 アクセスオプションも指定できます。 このファイルで指定できるオプションはたくさんありますが、 ここではほんの少しだけ言及します。exports(5) マニュアルページを読めば、 他のオプションは簡単にみつけられるでしょう。
いくつか /etc/exports の設定例を示します。
以下の例はファイルシステムのエクスポートの考え方を示しますが、
あなたの環境とネットワーク設定に応じて設定は少し変わるでしょう。
たとえば次の行は /cdrom
ディレクトリを、サーバと同じドメイン名か
(そのため、いずれもドメイン名がありません)、 /etc/hosts
に記述されている三つの例となるマシンに対してエクスポートします。 -ro フラグは共有されるファイルシステムを読み込み専用にします。
このフラグにより、
リモートシステムは共有されたファイルシステムに対して何の変更も行えなくなります。
/cdrom -ro host1 host2 host3
以下の設定は IP アドレスで指定した 3 つのホストに対して /home をエクスポートします。
この設定はプライベートネットワークで DNS が設定されていない場合に便利でしょう。 内部のホスト名に対して
/etc/hosts を設定するという手段もあります。
詳細については hosts(5)
を参照してください。 -alldirs
フラグはサブディレクトリがマウントポイントとなることを認めます。
言い替えると、これはサブディレクトリをマウントしませんが、
クライアントが要求するか、
または必要とするディレクトリだけをマウントできるようにします。
/home -alldirs 10.0.0.2 10.0.0.3 10.0.0.4
以下の設定は、サーバとは異なるドメイン名の 2
台のクライアントがアクセスできるように /a
をエクスポートします。 -maproot=root
フラグは、リモートシステムの root ユーザが、
エクスポートされたファイルシステムに root
として書き込むことを許可します。 -maproot=root
フラグが無ければ、 リモートマシンの root
権限を持っていても、
共有されたファイルシステム上のファイルを変更することはできないでしょう。
/a -maproot=root host.example.com box.example.org
クライアントがエクスポートされたファイルシステムにアクセスするためには、 そうする権限が与えられていなければなりません。 /etc/exports ファイルに クライアントが含まれているかどうか確認してください。
/etc/exports ファイルでは、 それぞれの行が一つのファイルシステムを一つのホストにエクスポートすることを表します。 リモートホストはファイルシステム毎に一度だけ指定することができ、 それに加えて一つのデフォルトエントリを置けます。たとえば /usr が単一のファイルシステムであると仮定します。 次の /etc/exports は無効です。
/usr/src client /usr/ports client
単一のファイルシステムである /usr は、2 行に渡って、同じホスト client へエクスポートされています。 この場合、正しい書式は次のとおりです。
/usr/src /usr/ports client
あるホストにエクスポートされるある 1 つのファイルシステムのプロパティは、 1 行ですべて指定しなければなりません。 クライアントの指定のない行は、単一のホストとして扱われます。 これはファイルシステムをエクスポートできる方法を制限しますが、 多くの場合これは問題になりません。
下記は、 /usr および /exports がローカルファイルシステムである場合の、 有効なエクスポートリストの例です。
# Export src and ports to client01 and client02, but only # client01 has root privileges on it /usr/src /usr/ports -maproot=root client01 /usr/src /usr/ports client02 # The client machines have root and can mount anywhere # on /exports. Anyone in the world can mount /exports/obj read-only /exports -alldirs -maproot=root client01 client02 /exports/obj -ro
変更が有効となるように、 /etc/exports が変更されたら mountd を再起動しなければなりません。 これは mountd プロセスに HUP シグナルを送ることで実行できます。
# kill -HUP `cat /var/run/mountd.pid`
他には、再起動すれば、FreeBSD はすべてを適切に設定します。 しかしながら、再起動は必須ではありません。 root 権限で以下のコマンドを実行すれば、すべてが起動するでしょう。
NFS サーバでは
# portmap # nfsd -u -t -n 4 # mountd -r
NFS クライアントでは
# nfsiod -n 4
これでリモートのファイルシステムを実際にマウントする準備がすべてできました。 この例では、サーバの名前は server で、 クライアントの名前は client とします。 リモートファイルシステムを一時的にマウントするだけ、 もしくは設定をテストするだけなら、クライアント上で root 権限で以下のコマンドを実行するだけです。
# mount server:/home /mnt
これで、サーバの /home ディレクトリが、クライアントの /mnt にマウントされます。もしすべてが正しく設定されていれば、 クライアントの /mnt に入り、 サーバにあるファイルすべてを見れるはずです。
リモートファイルシステムを起動のたびに自動的にマウントしたいなら、 ファイルシステムを /etc/fstab ファイルに追加してください。 例としてはこのようになります。
server:/home /mnt nfs rw 0 0
fstab(5) マニュアルページに利用可能なオプションがすべて掲載されています。
NFS には実用的な使用法がいくつもあります。 ここで典型的な使用法をいくつか紹介しましょう。
何台ものマシンで CDROM などのメディアを共有するように設定します。 これは安上がりで、たいていは、 複数のマシンにソフトウェアをインストールするのにより便利な方法です。
大規模なネットワークでは、 すべてのユーザのホームディレクトリを格納するメイン NFS サーバを構築すると、ずっと便利でしょう。 どのワークステーションにログインしても、 ユーザがいつでも同じホームディレクトリを利用できるように、 これらのホームディレクトリはネットワークに向けてエクスポートされます。
何台ものマシンで /usr/ports/distfiles ディレクトリを共有できます。こうすると、 何台ものマシン上に port をインストールする必要がある時に、 それぞれのマシンでソースコードをダウンロードすることなく、 直ちにソースにアクセスできます。
amd(8) (自動マウントデーモン) は、 ファイルシステム内のファイルまたはディレクトリがアクセスされると、 自動的にリモートファイルシステムをマウントします。 また、一定の間アクセスされないファイルシステムは amd によって自動的にアンマウントされます。 amd を使用することは、通常 /etc/fstab 内に記述する恒久的なマウントに対する、 単純な代替案となります。
amd はそれ自身を NFS サーバとして /host および /net ディレクトリに結びつけることによって動作します。 このディレクトリ内のどこかでファイルがアクセスされると、 amd は対応するリモートマウントを調べて、 自動的にそれをマウントします。 /net が、エクスポートされたファイルシステムを IP アドレスで指定してマウントするのに利用される一方で、 /host は、エクスポートされたファイルシステムをリモートホスト名で指定してマウントするのに利用されます。
/host/foobar/usr 内のファイルにアクセスすると、 amd はホスト foobar からエクスポートされた /usr をマウントします。
例 22-1. amd によるエクスポートされたファイルシステムのマウント
showmount コマンドを用いて、 リモートホストのマウントで利用できるものが見られます。 たとえば、foobar と名付けられたホストのマウントを見るために次のように利用できます。
% showmount -e foobar Exports list on foobar: /usr 10.10.10.0 /a 10.10.10.0 % cd /host/foobar/usr
例のように showmount はエクスポートとして /usr を表示します。 /host/foobar/usr にディレクトリを変更すると、 amd はホスト名 foobar を解決し、お望みのエクスポートをマウントしようと試みます。
amd は /etc/rc.conf 内に次の行を記述すれば、 起動スクリプトによって起動されます。
amd_enable="YES"
さらに amd_flags オプションによって amd にフラグをカスタマイズして渡せます。デフォルトでは
amd_flags は次のように設定されています。
amd_flags="-a /.amd_mnt -l syslog /host /etc/amd.map /net /etc/amd.map"
/etc/amd.map ファイルは、 エクスポートがマウントされるデフォルトオプションを決定します。 /etc/amd.conf ファイルは、 amd のより高度な機能の一部を設定します。
詳細については amd(8) および amd.conf(5) マニュアルページを参照してください。
訳: 渡辺 智雄 <tomo@jp.FreeBSD.org>. 6 September
1996.
ISA バス用のイーサネットアダプタの中には性能が悪いため、 ネットワーク、特に NFS で深刻な問題がおきるものがあります。 これは FreeBSD に限ったことではありませんが FreeBSD でも起こり得ます。
この問題は (FreeBSD を使用した) PC がシリコングラフィックス社やサン・マイクロシステムズ社などの高性能なワークステーションにネットワーク接続されている場合に頻繁に起こります。 NFS マウントはうまく動作するでしょう。 また、いくつかの操作もうまく動作するかもしれませんが、 他のシステムに対する要求や応答は続いていても、 突然サーバがクライアントの要求に対して応答しなくなります。これは、 クライアントが FreeBSD か上記のワークステーションであるときにクライアント側に起きる現象です。 多くのシステムでは、いったんこの問題が現われると、 行儀良くクライアントを終了する手段はありません。 NFS がこの状態に陥ってしまうと正常に戻すことはできないため、 多くの場合クライアントをリセットすることが唯一の解決法となります。
“正しい” 解決法は、より高性能のイーサネットアダプタを FreeBSD
システムにインストールすることですが、 満足に動作させる簡単な方法があります。
FreeBSD システムが サーバ
になるのなら、 クライアントからのマウント時に -w=1024
オプションをつけて下さい。FreeBSD システムが クライアント になるのなら、 NFS ファイルシステムを
-r=1024 オプションつきでマウントして下さい。
これらのオプションは自動的にマウントをおこなう場合には クライアントの fstab エントリの 4 番目のフィールドに指定してもよいですし、
手動マウントの場合は mount コマンドの -o
パラメータで指定してもよいでしょう。
NFS サーバとクライアントが別々のネットワーク上にあるような場合、 これと間違えやすい他の問題が起きることに注意して下さい。 そのような場合は、ルータが必要な UDP 情報をきちんとルーティングしているかを確かめて下さい。 していなければ、たとえあなたが何をしようと解決できないでしょう。
次の例では fastws は高性能ワークステーションのホスト
(インタフェース) 名で、 freebox
は低性能のイーサネットアダプタを備えた FreeBSD システムのホスト (インタフェース)
名です。 また /sharedfs はエクスポートされる NFS
ファイルシステムであり (exports(5) を参照) 、
/project はエクスポートされたファイルシステムの、
クライアント上のマウントポイントとなります。
すべての場合において、アプリケーションによっては hard や soft, bg
といった追加オプションがふさわしいかもしれないことに注意して下さい。
クライアント側 FreeBSD システム (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 は通常 (より小さいサイズへ分割されるかもしれませんが) 8�K の “ブロック” サイズで動作します。 イーサネットのパケットサイズは最大 1500 バイト程度なので、 上位階層のコードにとっては 1 つのユニットであって、 NFS “ブロック” は複数のイーサネットパケットに分割されるものの、 上位階層のコードにとっては 1 つのユニットであって、 ユニットとして受信され、組み立て直され、 肯定応答 (ACK) されなければなりません。 高性能のワークステーションは次々に NFS ユニットを構成するパケットを、 標準の許す限り間隔を詰めて次々に送り出すことができます。 小さく、容量の低いカードでは、 同じユニットの前のパケットがホストに転送される前に、 後のパケットがそれを踏みつぶしてしまいます。 このため全体としてのユニットは、再構成も肯定応答もできません。 その結果、 ワークステーションはタイムアウトして再送を試みますが、 8�K のユニット全体を再送しようとするので、 このプロセスは際限無く繰り返されてしまいます。
ユニットサイズをイーサネットのパケットサイズの 制限以下に抑えることにより、 受信した完全なイーサネットパケットについて個々に肯定応答を返せることが保証されるので、 デッドロック状態を避けられるようになります。
それでも、高性能なワークステーションが力任せに次々と PC システムにデータを送ったときには踏みつぶしが起きるかもしれません。 しかし、高性能のカードを使っていれば、NFS “ユニット” で必ずそのような踏みつぶしが起きるとは限りません。 踏みつぶしが起きたら、影響を受けたユニットは再送されて、 受信され、組み立てられ、肯定応答される十分な見込みがあります。
本文書、および他の文書は ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/ からダウンロードできます。
FreeBSD に関する質問がある場合には、ドキュメント を読んだ上で <questions@FreeBSD.org> まで (英語で)
連絡してください。
本文書に関する質問については、<doc@FreeBSD.org> まで電子メールを (英語で)
送ってください。