キャリアの初期、私はある一つの悩みを解決するためにあまりにも多くの時間を費やしました。それは、ベースのシステムを壊すことなく開発者がカスタマイズできる標準化されたOSを提供することです。バックアップは遅く、ディスクのクローニングは手間がかかりすぎました。そんな時、OverlayFSに出会いました。ファイルシステムをレイヤー化し、「ゴールデンイメージ」をクリーンな状態に保ちながら、すべての変更を軽量なディレクトリにキャプチャできるこの技術は、すべてを変えてくれました。
Union Filesystemの戦い：OverlayFS vs 旧世代
OverlayFSがバージョン3.18でLinuxカーネルに採用される前、私たちはAUFS（Advanced Multi-Layered Unification Filesystem）に苦戦していました。AUFSは強力でしたが、扱いにくいものでした。メインラインのカーネルに統合されなかったため、システム管理者はカスタムパッチを維持する必要があり、安定性の面で悪夢のようでした。
Device Mapperのスナップショットも選択肢の一つでした。これらはブロックレベルで動作します。しかし、100MBのファイルのうち1バイトでも変更すると、システムはファイルではなくブロックを管理しなければなりません。これはほとんどのワークロードにおいて非効率的です。一方、OverlayFSはファイルレベルで動作します。そのため、コンテナ化やLive USB環境において大幅に高速です。
本番環境では、そのメリットはすぐに現れます。しかし、罠もあります。5年間で20以上のLinuxノードを管理してきた経験から、オーバーレイマウントにおけるファイルロックは依然として予測不能な要素になり得ることを学びました。
メリット、デメリット、そしてiノード
本番環境では、そのメリットはすぐに現れます。しかし、罠もあります。5年間で20以上のLinuxノードを管理してきた経験から、オーバーレイマウントにおけるファイルロックは依然として予測不能な要素になり得ることを学びました。
メリット
- 圧倒的なパフォーマンス: OverlayFSはブロックレベルの変換に伴うオーバーヘッドをスキップします。ext4やXFSなどのホストファイルシステムと直接通信します。
- メモリの節約: 複数のコンテナがページキャッシュ内で同じ「lower」レイヤーを共有できます。30個のコンテナを運用したあるプロジェクトでは、RAMの使用量を約4GB削減できました。
- 即時のクリーンアップ: システムを工場出荷状態に戻したいですか？「upper」ディレクトリを削除するだけです。ミリ秒単位で完了し、稼働中のルートディレクトリで再帰的削除（rm -rf）を行うよりもはるかに安全です。
デメリット
- iノードの枯渇: すべてのファイルはベースディスク上のiノードを使用します。レイヤーをまたいで数百万の小さなファイルを扱う場合、ディスク容量（GB）がなくなるずっと前にiノードの制限に達してしまいます。
- POSIXの癖: レイヤー間でファイルを移動する際の
rename()などの操作が複雑になることがあります。最近のアプリの多くは問題ありませんが、古いデータベースエンジンなどはエラーを起こす可能性があります。 - ハードリンクの破損: 複数のハードリンクを持つファイルを編集すると「copy up（コピーアップ）」が発生します。これにより、マージされたビューにおいて、編集されたバージョンのリンクが実質的に切れてしまいます。
理想的なアーキテクチャ
OverlayFSの成功は、ディレクトリ戦略にかかっています。よくある間違いは、「work」ディレクトリを「upper」ディレクトリとは別のパーティションに配置してしまうことです。アトミックな移動を機能させるには、これらは同じファイルシステム上に存在する必要があります。
標準的なディレクトリ構造
/mnt/storage/base: 読み取り専用のソース (Lower)/mnt/storage/diff: 変更が保存される場所 (Upper)/mnt/storage/work: 内部メタデータに必要な空のフォルダ (Work)/mnt/unified: 実際にファイルを操作する場所 (Merged)
ハードウェアのアドバイス
高パフォーマンスなホストの場合、**upper**と**work**ディレクトリをNVMe SSDに配置してください。**lower**ディレクトリは低速なHDDでも構いませんが、すべてをフラッシュストレージに置くことで、「copy up」操作中のレイテンシを10msからマイクロ秒単位まで短縮できます。
実践的な実装
追加のソフトウェアは不要です。Ubuntu、Debian、AlmaLinuxを使用している場合、モジュールはすでに組み込まれています。
1. 基本的なマウント
テスト環境を構築してみましょう：
mkdir -p /tmp/overlay_test/{lower,upper,work,merged}
echo "ベースレイヤーのファイル" > /tmp/overlay_test/lower/base.txt
sudo mount -t overlay overlay \
-o lowerdir=/tmp/overlay_test/lower,upperdir=/tmp/overlay_test/upper,workdir=/tmp/overlay_test/work \
/tmp/overlay_test/merged/tmp/overlay_test/merged を確認すると、base.txt が表示されているはずです。そこで新しいファイルを作成すると、物理的には upper に保存されます。lower フォルダは変更されません。
2. レイヤーのスタッキング
これがDockerの背後にある「秘伝のソース」です。ベースOS、ウェブサーバー、そしてアプリケーションコードといったように、複数のlowerディレクトリを重ねることができます。
sudo mount -t overlay overlay \
-o lowerdir=/dir3:/dir2:/dir1,upperdir=/upper,workdir=/work \
/merged優先順位は左から右へ流れます。この場合、dir3 が最優先されます。
3. fstabによる永続化
再起動後もマウントを維持するには、/etc/fstab に以下を追記します。フルパスを使用し、オプションはカンマ区切りにしてください。
overlay /mnt/unified overlay noatime,lowerdir=/mnt/base,upperdir=/mnt/diff,workdir=/mnt/work 0 04. 永続的なLive USBのトリック
Live USBは通常、圧縮された読み取り専用の squashfs で動作します。OverlayFSを使用することで、その squashfs を lowerdir とし、書き込み可能なUSBパーティションを upperdir として利用できます。ユーザーはパッケージをインストールしたり作業を保存したりでき、再起動後もそれらは維持されますが、コアとなるOSは堅牢な状態に保たれます。
「Wrong FS Type」エラーのトラブルシューティング
マウントが一般的なエラーで失敗した場合は、dmesg | tail を実行してください。通常、以下の2つのいずれかが原因です。
- Dirty Workdir: workディレクトリが空ではない。
- XFS ftype: OverlayFSには
d_typeのサポートが必要です。古いCentOS 7システムなどでXFSを使用している場合、ftype=0でフォーマットされている可能性があります。OverlayFSを動作させるにはftype=1が必要です。これはxfs_info /mountpointで確認できます。
OverlayFSは、高レベルな柔軟性を提供する低レベルのツールです。Dockerのストレージコストの削減であれ、改ざん防止機能付きのキオスク端末の構築であれ、すべてのシステム管理者が備えておくべきセーフティネットを提供してくれます。
