4. NFS クライアントの設定

4.1. リモートのディレクトリをマウントする

作業をはじめる前に、手元の mount プログラムが十分に新しいかもう一度チェックしてください (Version 3 NFS を使いたければ 2.10m が必要です)。 またクライアントマシンが nfs マウントをサポートしているかも確認しておきましょう (大抵のディストリビューションではそうなっているでしょうが)。 2.2 以降のカーネルで /proc ファイルシステム が準備されている場合は、/proc/filesystems を読んで、nfs と書かれた行があるかを見て下さい。 ない場合は、 insmod nfs と入力してみてください。 NFS がモジュールとしてコンパイルされていれば、 nfs の行が魔法のように登場することでしょう。 これもだめなら、NFS サポートを組み込んだカーネルをビルド (あるいはダウンロード) する必要があります。 通常は、NFS が組み込まれていないカーネルで 以下に示すような mount コマンドを実行すると、 明らかにそれとわかるようなエラーになります。

マシンを NFS クライアントにするには、 そのマシンでポートマッパを動かす必要があります。 また NFS でファイルロックを使うには、 rpc.statdrpc.lockd とを、クライアントとサーバの両方で動かす必要があります。 最近のディストリビューションのほとんどでは、 デフォルトでこれらのサービスをブート時に起動するようになっています。 そうなっていない場合には、 Section 3.2 を見て起動方法を調べてください。

portmap, lockd, statd が動いたら、サーバのリモートディレクトリを (ローカルのハードドライブと同じように) mount コマンドを使ってマウントできるはずです。 前節からの例を使い続けることにしましょう: サーバは master.foo.com、 そしてこのサーバの /home ディレクトリを slave1.foo.com からマウントしたいとします。 この場合やらなければならないのは、 slave1.foo.com の root のプロンプトから 次のように入力するだけです。
   # mount master.foo.com:/home /mnt/home
  
これで master の /homeslave1/mnt/home として見えるはずです。 (このとき、空のディレクトリ /mnt/home はあらかじめマウントポイントとして作成してあると仮定しています。)

これがうまくいかない場合は、トラブルシュートの章 (Section 7) を見てください。

ファイルシステムを取り外すのも ローカルファイルシステムの場合と全く同じで、
   # umount /mnt/home 
  
と入力すれば OK です。

4.2. NFS ファイルシステムをブート時にマウントさせる

ローカルファイルシステムと同じように、 NFS ファイルシステムも起動時にマウントできます。 同様に /etc/fstab に追加すればいいのです。 違うのは、ファイルシステムのタイプを nfs にしなければならないことと、dump スイッチと fsck シーケンスの指定 (エントリの最後の 2 つ) を 0 にしなければならないこと、です。 よって前述の我々の例ならば、 /etc/fstab のエントリは次のようになります。
   # device       mountpoint     fs-type     options      dump fsckorder
   ...
   master.foo.com:/home  /mnt    nfs          rw            0    0
   ...
  

このファイルの書式に慣れていない人は、fstab の man ページを見てください。amd や autofs のようなオートマウンタを 使っている人は、マウントリストの対応するフィールドに、 (全く同じではないにせよ) よく似たオプションを指定することになります。

これで NFS が動作するようになったはずですが、 うまく動作させるにはまだ少々微調整が必要です。 また Section 6 も読んで、 ご自分の設定が十分安全かどうかを確認してください。

4.3. マウントのオプション

4.3.1. ソフトマウントとハードマウント

一緒につけておくと良いオプションがいくつかあります。 NFS サーバがクラッシュしたときやネットワークが切断されたときに、 クライアントがどう振る舞うかを指定するものです。 この状態を穏やかに扱えるのが NFS の良いところの一つです。 サーバの障害にあたっては二つのモードがあります。

soft

ファイルアクセスのリクエストに失敗すると、NFS クライアントは そのファイルアクセスを要求したプロセスにエラーを通知します。 このエラーを正しく扱えるプログラムもありますが、ほとんどはダメです。 この設定は「破損ファイルとロストデータの作り方」 みたいなもので、お勧めできません。 特にメールのディスクには使うべきではありません -- メールに価値を認めているならば。

hard

NFS マウントされたファイルシステム上のファイルにアクセスしている プログラムは、サーバがクラッシュすると宙ぶらりんになります。 これらのプロセスは intr を一緒に指定していない場合は、 中断することも kill することもできなくなります ("sure kill" を使えば別)。 NFS サーバが復活すると、 プログラムはそれぞれ何もなかったかのように再開します。 おそらくこちらが望ましい場合が多いでしょう。 全ての NFS マウントには、 hard,intr を用いることをお勧めします。

上記の例から採れば、fstab のエントリは次のようになるでしょう:
   # device             mountpoint  fs-type    options    dump fsckord
   ...
   master.foo.com:/home  /mnt/home   nfs      rw,hard,intr  0     0
   ...
  

4.3.2. ブロックサイズを設定して転送速度を最適化する

マウントオプションの rsizewsize は、クライアントとサーバが データをやりとりするときの、データの転送単位を指定するものです。

デフォルトの値は大きすぎ/小さすぎかもしれません。 全ての、あるいは大抵の設定に有効なサイズ、というものはありません。 例えば Linux カーネルとネットワークカードの組み合わせ (大抵は古いマシンでの話) によっては、あまり大きなブロックは扱えません。 一方大きなブロックが扱えれば、大きなサイズの転送は高速になります。

最適なブロックサイズを得る作業は、NFS の性能に重要な影響を与えます。 NFS を現場の環境で使う場合には必須と言えるでしょう。 詳細は Section 5 を見てください。