autofs マウントプロセス

マウント要求が発生したときに autofs サービスが何を実行するかは、オートマウンタマップの設定によって異なります。マウントプロセスの基本はすべてのマウントで同じですが、指定されているマウントポイントとマップの複雑さによって結果が変わります。Solaris 2.6 ではマウントプロセスも変更され、トリガーノードも作成されるようになりました。

単純な autofs マウント

autofs マウントプロセスの説明のために、以下のファイルがインストールされていると仮定します。

$ cat /etc/auto_master
# Master map for automounter
#
+auto_master
/net			-hosts			-nosuid,nobrowse
/home			auto_home		-nobrowse
/xfn			-xfn
/share		auto_share
$ cat /etc/auto_share
# share directory map for automounter
#
ws				gumbo:/export/share/ws

/share ディレクトリがアクセスされると、autofs サービスは /share/ws に対するトリガーノードを作成します。これは、/etc/mnttab の中では以下のようなエントリとなります。

-hosts  /share/ws     autofs  nosuid,nobrowse,ignore,nest,dev=###

/share/ws ディレクトリがアクセスされると、autofs サービスは以下の手順を実行します。

1. サーバのマウントサービスが有効かどうかを確認するために、サービスに対して ping を行います。

2. 要求されたファイルシステムを、/share の下にマウントします。これで、/etc/mnttab ファイルには以下のエントリが追加されます。

   -hosts /share/ws autofs nosuid,nobrowse,ignore,nest,dev=### gumbo:/export/share/ws /share/ws nfs nosuid,dev=#### #####

階層型マウント

オートマウンタファイルに複数の層が定義されていると、マウントプロセスは多少複雑になります。上記の例の /etc/auto_shared ファイルを拡張して以下のエントリを追加したとします。

# share directory map for automounter
#
ws       /       gumbo:/export/share/ws
                 /usr    gumbo:/export/share/ws/usr

この場合、/share/ws マウントポイントがアクセスされたときのマウントプロセスは基本的に最初の例と同じです。また、/share/ws ファイルシステムの中に次のレベル (/usr) へのトリガーノードを作成することにより、そのレベルがアクセスされたときにマウントできるようにします。 この例でトリガーノードが作成されるためには、NFS に /export/share/ws/usr が存在している必要があります。

階層を指定するときに、-soft オプションは使用しないでください。 この制限に関する説明は、「autofs アンマウント」を参照してください。

autofs アンマウント

一定時間アクセスがないためにアンマウントされるときは、マウントと反対の順序で実行されます。あるディレクトリより上位のディレクトリが使用中であれば、それより下のディレクトリだけがアンマウントされます。 アンマウントすると、トリガーノードがすべて削除され、ファイルシステムがアンマウントされます。ファイルシステムが使用中であれば、アンマウントは失敗してトリガーノードは再インストールされます。

階層的にマウントを指定する場合は、-soft オプションは使用しないでください。-soft オプションを使用すると、トリガーノードを再インストールする要求がタイムアウトすることがあります。トリガーノードを再インストールできないと、マウントの次の階層にアクセスできません。この問題は、オートマウンタがすべての階層の構成要素をアンマウントすることでしか回避できません。具体的には、ファイルシステムが自動的にアンマウントされるのを待つか、システムをリブートすることになります。