ファイルシステムはどう機能するか: inode、journaling、page cache?

Question

IT Interview Practice · Accepted Answer

**ファイルシステム (filesystem)** は、ディスクブロックのフラットな配列をファイルとディレクトリの階層に変え、それを信頼でき高速にするためにメタデータと空き領域を管理します。

## Inode: ファイルはメタデータ + ブロックポインタ

UNIX ファイルシステムでは、すべてのファイルは **inode** (index node) です — ファイルの **メタデータ** (サイズ、所有者、権限、タイムスタンプ、リンク数) と **データブロックへのポインタ** を保持する構造です。inode が保存 *しない* ものに注意: **ファイル名** です。名前は **ディレクトリ** に存在し、それは名前 → inode 番号をマッピングするただのファイルです:

```text
directory "docs"                  inode 1042              data blocks
┌───────────────────┐            ┌──────────────┐         ┌────────┐
│ "report.txt" →1042│───────────▶│ mode, uid    │──ptr───▶│ block  │
│ "notes.txt"  →1050│            │ size, times  │──ptr───▶│ block  │
└───────────────────┘            │ link count=2 │         └────────┘
                                 │ block ptrs   │──(indirect)──▶ ...
                                 └──────────────┘
```

だから **ハードリンク (hard link)** は同じ inode を指す 2 つ目のディレクトリエントリにすぎず (リンク数 2)、`rm` は実は `unlink` です — 名前を削除し、リンク数がゼロに達したときだけ inode を解放します。

## Journaling: クラッシュを生き延びる

単一の論理操作 (例: append) は複数のブロック — inode、空き領域ビットマップ、データ — に触れます。途中でのクラッシュはファイルシステムを不整合なまま残します。**journal** はまず意図した変更をログに書き、それから適用します。クラッシュ後、ファイルシステムは低速な全走査 (`fsck`) の代わりに journal を再生 (replay) または破棄します。モードは安全性と速度を天秤にかけます: **メタデータのみ** の journal (高速、一般的) 対 メタデータ **とデータ**。

## Page cache と I/O パス

kernel はファイルデータを RAM の **page cache** にキャッシュするので、再読み取りはメモリに当たり、書き込みは **バッファリング** されて後でフラッシュされます (write-back):

```text
buffered I/O (default): app ↔ page cache ↔ disk   → cached, async writeback, fast re-reads
direct I/O (O_DIRECT):  app ↔ disk                → bypass the cache; DBs manage their own
fsync():                force buffered data to durable storage (required for real durability)
```

Buffered I/O は高速ですが、「書き込まれた」データは `fsync` まで永続的ではありません。データベースはしばしば **direct I/O** に独自のバッファプールを加えて、キャッシュと永続性を精密に制御します。

## なぜ重要なのか

ファイルシステムの内部は日常の挙動を説明します: なぜハードリンクが機能するか、プロセスがまだ開いているファイルを削除しても閉じるまで領域が解放されない理由、なぜ `fsync` が永続性に不可欠か (省略すると典型的なデータ消失バグ)、ファイルの 2 回目の読み取りがなぜ瞬時か (page cache)。シニアエンジニアは、データベース向けに buffered か direct I/O を選ぶとき、キャッシュ用に RAM を見積もるとき、クラッシュ整合性の問題をデバッグするときに、これらを推論します。

Inode: ファイルはメタデータ + ブロックポインタ

Journaling: クラッシュを生き延びる

Page cache と I/O パス

なぜ重要なのか

関連する質問