コンテナのオーバーレイファイルシステム（OverlayFS）

OverlayFSが解く問題

コンテナイメージは「ベースOS＋パッケージ追加＋アプリ配置」のように、変更を積み重ねたレイヤの集合です。同じベースイメージから100個のコンテナを起動するとき、各コンテナにイメージ全体を物理コピーしていたら、ディスクも起動時間も100倍かかります。

OverlayFS はこれを ユニオンマウント で解く Linux カーネルのファイルシステムです。複数のディレクトリを縦に重ね、上のレイヤが下を隠しながら透ける1枚のビューを作ります。読み取り専用の共通部分は全コンテナで物理的に1つだけ持ち、書き込みはコンテナ固有の薄い層に閉じ込めます。仮想ファイルシステムの上に被さる擬似ファイルシステムという点で、VFS抽象化レイヤ の上に乗る一種のスタッカブルFSです。

4つのディレクトリ：lower / upper / work / merged

OverlayFS のマウントは4種類のディレクトリで構成されます。それぞれ役割が厳密に分かれています。

マウントは次のように行います。

mount -t overlay overlay \
  -o lowerdir=/img/base:/img/pkg,upperdir=/c1/upper,workdir=/c1/work \
  /c1/merged

lowerdir は左ほど上位です。上の例では同名ファイルがあれば pkg より base が、それより upper が優先されます。読み取りは merged を上から下へ探索し、最初に見つかった実体を返します。書き込みはすべて upper に向かいます。

copy-up：lowerのファイルを変更する瞬間に複製する

lower は読み取り専用です。では merged 上で lower 由来のファイルを書き換えるとどうなるか。OverlayFS は 書き込みの直前に、そのファイルを lower から upper へ丸ごと複製 します。これが copy-up です。これは コピーオンライト の発想をファイル単位で適用したものです。

初期状態:                書き込み後:
  upper: (空)              upper: /app/config.yml ← ここに複製され編集される
  lower: /app/config.yml   lower: /app/config.yml （元のまま、隠れる）
  merged: config.yml       merged: config.yml ＝ upper側を見る

copy-up の手順を擬似コードで示します。

copy_up(path):
  if path が既に upper にある: return   # 二度目以降は不要
  workdir に一時ファイルを作成
  lower の中身・所有者・モード・xattr を一時ファイルへ複製
  rename(workdir/tmp, upper/path)       # 原子的に upper へ昇格
  以降この path への I/O は upper を直接対象にする

重要なのは 粒度がファイル全体 である点です。1GBのファイルの1バイトを変えるだけでも1GB全体がコピーされます。書き込み主体のワークロードではこのコストが無視できないため、データベースの実体ファイルなどはボリュームマウントで OverlayFS を迂回するのが定石です。

whiteout：削除を「特殊エントリ」で表現する

lower のファイルを merged 上で削除する場合も、lower は変更できません。実体は lower に残ったままなので、「上から見たら無い」状態を作る必要があります。OverlayFS は upper に whiteout という目印を置いて、下層の同名エントリを隠します。

whiteout はキャラクタデバイスファイルで、デバイス番号 0/0 を持つものとして表現されます。merged 探索中にこのエントリに当たると、OverlayFS はそこで打ち切り、下層を見に行きません。結果として「削除されたように見える」わけです。

rm merged/app/old.log を実行すると:
  upper/app/old.log → デバイス番号 0/0 の whiteout を作成
  lower/app/old.log → そのまま残存（が、隠される）
  merged から old.log は消えて見える

ディレクトリ全体を削除して同名で作り直す場合は、個々のwhiteoutでは表現しきれません。このとき upper 側のディレクトリに trusted.overlay.opaque="y" という拡張属性（xattr）を付け、そのディレクトリは下層を一切透かさない（opaque） と宣言します。opaque ディレクトリでは lower の同名ディレクトリ配下が完全に無視されます。

レイヤ共有：イメージ1つでコンテナ多数

ここまでの仕組みを組み合わせると、コンテナイメージの共有が自然に実現します。イメージの各レイヤは読み取り専用ディレクトリとして展開され、複数コンテナの lowerdir として 物理的に同じ実体を共有 します。コンテナごとに違うのは upper と work だけです。

共有される lower（イメージレイヤ、読み取り専用・1セットのみ）:
  /img/L1 (base OS) ── /img/L2 (runtime) ── /img/L3 (app)
        ▲                    ▲                   ▲
        └──────── 全コンテナが同じ実体を参照 ────┘

コンテナ固有（書き込み可能・コンテナごとに1つ）:
  コンテナA: upperdir=/A/upper  workdir=/A/work  → /A/merged
  コンテナB: upperdir=/B/upper  workdir=/B/work  → /B/merged
  コンテナC: upperdir=/C/upper  workdir=/C/work  → /C/merged

この構造から効果が直接導けます。

• 起動が速い: コンテナ起動時に作るのは空の upper/work と merged のマウントだけ。イメージ本体のコピーは発生しないので、サイズに関係なく一瞬で起動する。
• 容量が小さい: 共有 lower はディスク上に1セットだけ。コンテナが消費するのは copy-up された差分と新規ファイル（＝upper の中身）だけ。
• 破棄が安全: コンテナを捨てるときは upper/work を消すだけ。共有 lower は無傷なので、他のコンテナや次回起動に一切影響しない。

Docker や containerd の overlay2 ストレージドライバはまさにこの構成で、各イメージレイヤを内容ハッシュで識別される読み取り専用ディレクトリとして保存し、複数イメージ間でも共通レイヤを使い回します。名前空間でファイルシステムビューを隔離する namespaces と cgroups と組み合わさって、軽量なコンテナが成立します。

制約と注意点

OverlayFS は便利ですが、レイヤを重ねる代償もあります。

• copy-up のコスト: 前述の通りファイル単位で複製するため、大きなファイルへの書き込みは重い。書き込み集約的なデータは VFS 経由でボリューム（bind mount や named volume）に逃がす。
• inode と hardlink: copy-up すると upper 側は lower とは別 inode になる。lower 内でハードリンクされていたファイル群は、copy-up 後にリンク関係が壊れる場合がある（index=on である程度緩和）。
• rename の制約: ディレクトリ rename はレイヤをまたぐと単純な rename(2) では済まず、redirect_dir 機能の有無で挙動が変わる。
• lower の不変性: lower を直接書き換えるとオーバーレイの整合が崩れる。lower は read-only として扱うのが大前提。

これらは「読み取り共有・書き込み分離」という設計の裏返しであり、制約を理解した上でレイヤ設計（変更頻度の高いものを上位レイヤへ）を行うことが、イメージの効率化につながります。

まとめ

• OverlayFS は 読み取り専用の lower 群と書き込み可能な upper を重ね、上から透けて見える1枚の merged ビューをユニオンマウントとして提供する。
• lower のファイルを変更すると初回だけ copy-up で upper へ丸ごと複製し、削除は whiteout（0/0 のキャラクタデバイス）、ディレクトリの隠蔽は opaque xattr で表現する。work ディレクトリは原子的な昇格のための作業領域。
• 全コンテナが lower を 物理共有 し、固有の upper/work だけを持つため、コンテナは起動が速く・容量が小さく・破棄が安全になる。これがコンテナ軽量性の正体。
• 仕組みの根は コピーオンライト と VFS抽象化レイヤ、隔離の文脈は namespaces と cgroups も参照。