同じファイルシステムを複数のポイントにマウントできないのはなぜですか。また、マウントポイントのiノード参照カウントを1より大きくできないのはなぜですか。
私は読んでいますnixオペレーティングシステムの設計 Maurice J Bachによるもので、ファイルシステムのマウントに関して2つの質問があります。
ファイルテーブルでマウントポイントiノードの参照カウントが1より大きい場合、ファイルシステムのマウントが失敗するのはなぜですか？
Unixが複数のポイントでのファイルシステムのマウントを許可しないのはなぜですか？ （これが許可された場合、どのような悪いことが起こる可能性がありますか？）
mount(2) のHP（HP-UX）のマニュアルページには次のように書かれています。
Mount（）が失敗した場合、errnoは次のいずれかの値に設定されます。
- _
[EACCES]_パスプレフィックスのコンポーネントが検索権限を拒否します。 - _
[EBUSY]_pathは現在マウントされているか、誰かの現在の作業ディレクトリであるか、そうでなければビジーです。 - _
[EBUSY]_ fsに関連付けられているファイルシステムが現在マウントされています。
質問（1）が当てはまる場合、最初のEBUSYが得られます。理由は次のとおりです。
- ディレクトリがすでにマウントポイントである場合、以前にマウントされたディレクトリにアクセスできなくなり、以前のマウントは無関係になります。
- ディレクトリ（たとえば_
/some/where_）がプロセスの現在のディレクトリである場合、_/some/where_の内容の異なるビューを持つプロセスがあります。新規参入者はマウントされたファイルシステムの内容を確認しますが、古いプロセスはマウントされたディレクトリの内容を確認します。
ファイルシステムがすでにマウントされている場合、質問（2）に答えるために2番目のEBUSYを取得します。つまり、2回マウントすることはできません。これは良いことです-実際に共有されているときにスーパーブロックなどに排他的にアクセスできると仮定して、2つの別々のマウントポイントが両方とも回った場合、混乱の恐ろしい危険があります。同じデバイスが_/some/where/newfile_と_/opt/other/newfile_の両方にマウントされているため、ファイルを作成する_/some/where_も同時に_/opt/other_を作成する場合も混乱します。
AIX、Solaris、Linux、MacOS X、BSDのマニュアルページでmount(2)を確認していませんが、動作は同じであると思います。
これは直接的な答えではありませんが、mount --bindを使用すると、2か所にマウントするのと同様の動作を得ることができます。
基本的に、1つのファイルシステムを複数の場所にマウントする可能性は、ツリー階層ファイルシステムの概念を破り、有向非巡回グラフに変換します（マウントされたファイルシステムをそのシェルフのサブディレクトリにマウントして、可能な循環的で無向のファイルシステムにさらに分割することもできます一般的なグラフ）。基本的に、問題は、マウントされたルートディレクトリの..エントリを使用して親ディレクトリに渡そうとするときに、親に到達するために、現在いくつかの親ディレクトリのどれに従うかを選択する必要があることです。
Linuxでは、マウントする--bindオプションがあり、ディレクトリ（ファイルシステムのルートディレクトリである必要はありません）を他の場所（マウントされたファイルシステムではなくプレーンディレクトリ）にマウントできます。/procや/ sysファイルシステムなどをchroot（2）edプロセスにマウントして、このフレームワークにアクセスできるようにすることができます。
この種のマウントは、ファイルへのソフトリンクとハードリンクの違いと同じ意味で異なります。カーネルによって異なる方法で処理され、ルートファイルシステムごとに真のマウントポイントのみが許可されます。その理由は、ハードリンクではループを作成できず、ソフトリンクでは作成できるのと基本的に同じです。マウントされたファイルシステムを再度マウントすることはできません。また、同じディレクトリをmount --bindすることもできます。