ファイルシステムのマウントと名前空間の伝播

マウントは「ポイント」のツリーである

mount というと「デバイスをディレクトリに繋ぐ」操作だと捉えがちですが、カーネル内部の実体は マウントポイントのツリー です。ある ファイルシステム のルートを、既存ツリー上の任意のディレクトリ（マウントポイント）に接ぎ木すると、その地点から下の名前解決が新しいファイルシステムへ切り替わります。マウントは入れ子にでき、あるマウントの上にさらに別のマウントを重ねられます。結果として、プロセスが見るファイル空間は 複数のマウントが連結した1本のツリー になります。

カーネルは各マウントを struct mount で表し、これは「どのスーパーブロック（FS実体）を、親マウントのどの地点（マウントポイントの dentry）に繋いだか」を保持します。重要なのは、同じスーパーブロックを複数の地点にマウントできる ことと、マウントは mount 名前空間 ごとに別インスタンスとして保持される ことです。/proc/self/mountinfo を読むと、各マウントの ID・親 ID・マウント元・伝播種別まで一覧できます。

共有サブツリー：伝播の4種別

マウント名前空間を CLONE_NEWNS で複製すると、親のマウントツリーが コピー されます。ここで問題になるのが、「片方の名前空間で新しくマウントしたとき、それをもう片方にも反映するか」です。これを制御するのが マウント伝播（mount propagation）、別名 共有サブツリー（shared subtrees） の仕組みです。各マウントは次の4種別のいずれかを持ちます。

ここで言う peer グループ とは、互いに shared な関係で結ばれたマウントの集合です。同じ peer グループに属するマウントの1つで mount/umount が起きると、そのイベントが他の全メンバの対応する地点へ複製されます。slave は peer グループに対して 片方向の従属 であり、マスタ側 peer グループのイベントは受け取るが、自分の側で起きたイベントはマスタへ送り返しません。

なぜ4種別が必要か：双方向と片方向の使い分け

伝播種別の存在意義は、情報の流れ方向を地点ごとに設計する ことにあります。具体例で考えます。ホストに USB メモリを挿すと、/media/usb に自動マウントされるとします。

• この地点が shared なら、ホストの mount イベントが peer グループを通じて全コンテナへ伝播し、各コンテナの対応地点にも USB が現れます。逆にコンテナ内で何かをマウントすると、それがホストや他コンテナへ漏れます。これは通常望ましくありません。
• そこで多くのランタイムは、ホスト側を shared、コンテナ側を slave にします。すると「ホスト → コンテナ」の片方向だけが通り、ホストの USB はコンテナに見えるが、コンテナ内のマウントはホストへ波及しません。これが「デバイスは見せたいが隔離はしたい」要求の答えです。
• 完全に切り離したい領域は private にします。/proc を私的にマウントし直したコンテナの内部マウントが、決してホストへ漏れないのはこの種別のおかげです。

bind マウントと再帰 bind

伝播と並ぶもう一つの基本が bind マウント です。これは「既にツリー上に存在するサブツリーを、別の地点にもう一度見せる」操作です。新しいファイルシステムを繋ぐのではなく、同じファイル群への2つ目の窓 を作ります。

# /data の中身を /srv/app/data にも見えるようにする
mount --bind /data /srv/app/data

ここで重要な区別が bind と rbind（再帰 bind） です。素の --bind は 指定した1つのマウントだけ を写します。そのサブツリーの内側にさらに別のマウント（入れ子マウント）があっても、それらは写りません。一方 --rbind は 配下のマウントツリー全体を再帰的に複製 します。

mount --bind  /a /b   # /a 直下のFSだけ複製。/a/x にあった別マウントは /b/x に現れない
mount --rbind /a /b   # /a 配下の入れ子マウントもすべて /b 配下に再現される

伝播と bind は直交する概念ですが、組み合わさって効きます。rbind で複製したとき、複製先の各マウントの伝播種別は 元マウントの種別と、複製操作の文脈 で決まります。元が shared なら複製先も同じ peer グループに加わり双方向に繋がります。これが意図しない漏れの原因になりやすいため、コンテナ構築では rbind の前後で種別を明示制御するのが鉄則です。unbindable は、こうした再帰 bind の際に「この地点は複製対象から外す」ことを宣言し、不要なマウントの増殖を防ぎます。

コンテナでの活用：再帰 private 化から slave 調整へ

ここまでの部品が、コンテナの安全なファイルシステム隔離を成立させます。名前空間と cgroups によるコンテナ化で、マウント名前空間がまず分離されますが、複製直後はホストと shared な関係が残っていることがあります。そこでランタイムは典型的に次の順序で組み立てます。

1. unshare(CLONE_NEWNS)            # mount 名前空間を分離（ツリーはまだ親と共有関係を持ちうる）
2. mount --make-rprivate /         # ルート配下を再帰 private 化 → ホストへの漏れを全断
3. 必要なホスト資源を rbind で持ち込み、個別に slave/ro へ調整
4. pivot_root(2) で新ルートへ切替、旧ルートを umount して参照を断つ

ステップ2の 再帰 private 化 が安全の要です。これを怠ると、コンテナ内のマウント操作がホストの peer グループへ伝播し、ホストや兄弟コンテナのマウントツリーを汚染し得ます。逆に、ホストのデバイス更新を見せたい特定地点だけを後から slave へ戻すことで、「全体は隔離・一部だけ片方向追従」という細かな制御が実現します。ルート切り替えに chroot ではなく pivot_root(2) を使うのは、旧ルートを退避してから umount でき、旧ルートへの参照を完全に断てる ためです（脱出経路を残さない）。

このマウントツリーの隔離は、各プロセスが自分専用のファイル空間を持つことを意味し、ファイルディスクリプタ を通じた実際の I/O 経路とは独立に「見え方」だけを変えます。読み取り共有・書き込み分離を担う OverlayFS が「中身のレイヤ」を、マウント伝播が「ツリーのつながり方」を受け持つ、と整理すると役割分担が明確になります。

まとめ