私のシステムには、次のインストールオプションが定義されています。ストレージの中断が発生した場合、(bg,hard,nointr)
この理由でコンソールアクセスがロックされますか?
storage:/vol/myvol on /test type nfs (rw,bg,hard,nointr,rsize=65536,wsize=65536,tcp,nfsvers=3,timeo=600)
どのnfsオプションの組み合わせが正しいアプローチと見なされますか?
答え1
すべてのNFSマウントオプションには長所と短所があります。
bg
つまりmount
、ファイルシステムにアクセスしようとすると(通常はシステム起動中)、サーバーがタイムリーに応答しない場合、マウントはバックグラウンドで実行されているプロセスを分岐し、定期的にマウントを再試行します。bg
このオプションを使用しないとmount
再試行され、mount -a
マウントが成功または失敗するまで終了しません(または他のファイルシステムをマウントし続ける場合)。頻繁にシャットダウンするサーバーからファイルシステムをマウントする必要があるため、システムの起動が遅れたくない場合は、この
bg
オプション(または自動マウント)を使用してください。このオプションの欠点は、
bg
リモートファイルシステムがマウントされていない状態でシステムが起動できることです。これにより、ファイルシステムを使用しようとしているアプリケーションが失敗する可能性があります(または、悪いことに、記録したい内容でリモートファイルシステムを埋める可能性があります)。ローカルディスク)リモートファイルシステム)。したがって、使用は
bg
あなたがしなければならない選択です。hard
soft
ファイルシステムをマウントした後に適用されます。リモートサーバーがクラッシュまたは接続できない場合、ハードインストールは引き続きI / O要求を無期限に再試行します。
ソフトインストールはアプリケーションにエラーを返し、通常はローカルディスクドライブの電源が切れたかのように回復できないエラーとして扱います。アプリケーション実行可能ファイル自体がソフトマウントされてアクセスできないリモートファイルシステムにある場合、ローカルカーネルがリモートファイルシステムからページを取得する必要があるときにアプリケーションが終了します。
したがって、選択はあなた次第です。リモートサーバー(またはネットワーク)がダウンしたときにプログラムが失敗するようにしますか、またはリモートサーバーに再接続できるまでI / Oを無期限に再試行しますか?
ハードマウントを使用すると、リモートサーバーに障害が発生しても、ローカルディスクを使用するプログラムが(通常は短い)期間中に中断されないように、リモートファイルシステムを使用するすべてのプログラムはシグナルによって中断されません。ディスクI / Oを実行するのに必要な時間。これはプログラムが中断されて使用できなくなるため、ユーザーにとってがっかりする可能性がありますcontrol-C。 NFS i/o を待つプログラムを中断するには、
intr
マウント・オプションを含めます。通常、このオプションを使用するのはintr
安全です。プログラムがEINTR
中断されたときにI / Oエラー(エラー)が表示されることがあることに注意してください。
私が提案する1つのことは:失敗する可能性があるリモートサーバーでハードマウントされたNFSファイルシステムを使用するとき、欲しくない/
(たとえば)のディレクトリにファイルシステムをマウントする/test
か、実際にマウントします。どのディレクトリは、多くの人が使用するのと同じレベルにあります。たとえば、Cライブラリはディレクトリツリーを参照してディレクトリを操作するためです/home/username
。アプリケーションが応答しないハードマウント NFS マウントポイントで操作を実行すると、ハングします。pwd
stat
stat
pwd
これが、ユーザーがNFSについて文句を言う主な理由です。シェルが何かを行い、NFSファイルシステムがダウンして使用する必要もないため、ログインできません。これがホームディレクトリに自動マウントを使用するもう一つの良い理由です。
NFSマウントのベストプラクティスは次のとおりです。
- 自動インストーラの使用
- そうでない場合は、各リモートファイルシステムを/ n /にマウントします。リモートサーバー名/ファイルシステム名オプションがあります
hard,intr
。 - /nおよび/n/リモートサーバー名NFSマウントポイントであるローカルディレクトリではありません。
- 構成
updatedb
や他の何も/n
。