FAQ の章です。ここのほとんどは Alan Cox が書いたものです。
can't register with portmap: system error on send
Caldera のシステムをお使いではありませんか?このシステムには rc スクリプトにバグがあります。 Caldera に連絡して修正版を手に入れて下さ い。
効率上の理由で、 nfsd が open ファイルハンドラをキャッシュするから です(nfsd がユーザ領域で実行されていることを思い出して下さい)。 nfsd がファイルをオープンしている間(つまりそのファイルに書き込みを行った後) には、カーネルはそのファイルに実行許可を与えません。 95 年の春以降の nfsd では、このファイルハンドラのリリースは数秒で終了しますが、古いも のでは数日もキャッシュしたままのこともあります。
Linux の NFS サーバはデフォルトではリードオンリーです。 exports と
nfsd の man ページを読んで下さい。/etc/exports
を修正する必要
があるでしょう。
古いバージョンでは rsize=1024,wsize=1024
をつけてマウントする
必要があります。
その範囲以外のブロックサイズを使って下さい。
今のところできません。
NFS を使うユーザが 8 つ以内のグループに収まっていることを確認して下 さい。古いサーバではこの条件が必要なことがあります。
リブートや停止するときには NFS サーバを umount せず、単に無視して下
さい。 umount しなければ何も問題を起こすことはありません。コマンドは
umount -avt nonfs
となります。
NFS の書き込みは通常同期的に行われます(もしデータを失う危険性を気 にしなければこれを無効にすることもできます)。悪いことに、BSD から由来 したカーネルにおいては、小さなブロックにおいてこれがうまく機能しない場 合があるのです。例えば Linux から 4K のデータを 1K のパケットに分けて 書き込もうとすると、 BSD は以下のような動作を行います。
read 4K page
alter 1K
write 4K back to physical disk
read 4K page
alter 1K
write 4K page back to physical disk
etc..
まともなシステムではこの問題は起きません。しかしいずれにせよ Linux のクライアントがそれほど高速ではないことも事実です。
はい、全くその通りです。ちゃんと設定されていない状態で NFS を走らせ るのは、自宅の玄関に「休暇中」という札をぶら下げたまま玄関を開けっ放し にして、さらに知っている限りの犯罪者達に自宅への地図を送り付けるような ものです... 比較的安全な環境や、あるいは間抜けな間違いをしてもデータを 復活できるような場合には問題は少ないです。最悪なのは、NFS マウントした ディスクのファイルを壊しまくったり、マシンをクラッシュさせてしまったり することです。システムファイルを書き込み可能でマウントしなければ、まだ 少しは安全かもしれませんが。
NFS が Unix で共通にサポートされている唯一のファイル共有プロトコル だからです。また大抵はうまく動くからです。
サーバが停止したときの NFS の振る舞いには主に以下の3つがあります。
数回試みても NFS サーバからの答えが帰ってこないと、 NFS クライアントは 使われているプロセスにエラーを通知します。このオプションを使う場合は、 ソフトがこの通知を正しく処理できるかを確認して下さい。個人的にはこの設 定はお勧めしません。
NFS クライアントは kill されるまで永遠に接続を試み続けます。 NFS サー バが復活するかリブートすると動作も回復します。
hard と似ていますが Ctrl-C によって宙ぶらりんになったプロセスを中断す ることができます。しかし、例えば /usr/spool/mail への NFS マウントなど の場合はうまく行かないことがあります。メールをチェックしている間はシェ ルは Ctrl-C を無視するからです... しかし私はこの設定を全ての NFS マウントに用いるべきだと思います。メールスプールにもです。