ファイルシステムのクラッシュ整合性とfsync保証

クラッシュ整合性とは何を守ることか

ファイルシステムへの1回の論理的な操作（追記、リネーム、ファイル作成）は、ディスク上では 複数の独立したブロック更新 に分解されます。ストレージはこれらをまとめて原子的に書く手段を持たないため、途中で電源が落ちれば一部だけが永続化された 中間状態 が残ります。

ここで区別すべきは2種類の整合性です。メタデータ整合性（ファイルシステム構造が矛盾しない、たとえば「inode が指すブロックが空きビットマップ上でも使用中になっている」）と、データ整合性（アプリが書いた中身がそのまま残る）です。多くのファイルシステムが既定で保証するのは前者だけで、後者は fsync などでアプリが明示的に要求しない限り守られません。「FS は壊れていないが、直前に書いた内容は消えた」は仕様どおりの挙動です。

クラッシュ整合性の核心は 原子性の擬似的な実現 です。本来非原子的な複数更新を、復旧後に「全部反映済み」か「全く反映していない」のどちらかにだけ収束させ、半端な中間状態を観測させない。これを達成する代表的な手法が、ジャーナリング・CoW・ログ構造の3つです。

手法1：ジャーナリング（先行書き込みログ）

ジャーナリングは「これからこう書く」という更新計画を専用のログ領域に 先に 記録し、本番領域へはその後で反映します。これは Write-Ahead Logging（WAL、先行書き込みログ）そのもので、DB のトランザクションログと原理を共有します。

1. 更新するブロック群をジャーナル領域へ書く
2. バリア（FLUSH/FUA）で 1 の永続化を待つ
3. コミットレコードを書き、トランザクション完了を確定する
4. 後で本番位置へ反映する（checkpoint）

整合性の鍵は 手順2と3の順序 です。コミットレコードより前にすべての更新が永続化済みであることをバリアで保証してからコミットを書くため、復旧時には二者択一だけが起こります。コミットレコードがある → 完全なので本番へ 再適用（redo） する。ない → 不完全なので 丸ごと破棄 する。半端な状態が原理的に発生しないため、fsck の全走査は不要になり、ログ再生だけで一貫性が戻ります。詳しい内部は ジャーナリングファイルシステムの内部（ext4/XFS） を参照してください。

手法2：コピーオンライト（CoW）

CoW は既存ブロックを 決して上書きせず、変更を常に別の空き領域へ書きます。書き換えたブロックを指していた親ブロックも新しい位置へ書き直され、これがルートまで連鎖します。最後にスーパーブロック内のルートポインタを 1つだけ原子的に差し替える ことで、新旧どちらかの完全な木だけが見える状態を保ちます。

更新前: root → A → B(旧)
更新中: B'(新) を空き領域へ書く → A'(B'を指す) を書く
確定:   root のポインタを A' へ差し替え（この1書き込みが原子的境界）

ジャーナリングと違い、CoW は「古い状態」が上書きされずに残るため、ログ再生という別工程が要りません。クラッシュ時はルート差し替えが起きたか否かだけで結果が決まります。同じ仕組みからスナップショット（古いルートを保持するだけ）が自然に導かれます。詳細は コピーオンライト型ファイルシステム（ZFS/Btrfs） を、原理としての CoW は コピーオンライト を参照してください。

手法3：ログ構造とWALの共通原理

ログ構造化ファイルシステム（LFS）は、すべての書き込みをディスク上の 一本の連番ログ に追記し続け、その場上書きを一切しません。最新のデータがログのどこにあるかは inode マップで引きます。書き込みが常に末尾追記になるため、ランダム書き込みがシーケンシャルに変換され、フラッシュメモリの FTL や一部の組み込み FS で採用されています。

ここまでの3手法は、表面上は別物に見えて 同じ不変条件 を共有しています。

共通原理は3つです。第一に その場上書きを避ける（ログへ追記、または別領域へ書く）。第二に 単一の原子的書き込みで新旧を切り替える（コミットレコード、ルートポインタ）。第三に その原子的書き込みより前に依存物の永続化を強制する（バリア）。WAL がトランザクション境界をログレコードで確定するのと、CoW がルート差し替えで確定するのは、抽象的には同じ「一点の原子的コミットへ全更新の見え方を集約する」設計です。

fsync / fdatasync / O_SYNC の保証範囲

通常の write は ページキャッシュ に書いて即座に返るだけで、ストレージには届いていません。永続化を要求する手段が同期系のシステムコールです。それぞれ守る範囲が異なります。

fdatasync の境界は誤解されやすい点です。「メタデータを書かない」のではなく、「書いたデータを後で正しく読み出すために必須のメタデータは書く」が正確です。たとえばファイルを末尾に追記してサイズが伸びた場合、新しいサイズを永続化しないとそのデータは読めないため、fdatasync でもサイズは書きます。省けるのは更新時刻（mtime）のように、データの読み出しに無関係なメタデータだけです。

クラッシュセーフな原子的差し替えの定石:

  fd = open("data.tmp", O_CREAT|O_WRONLY)
  write(fd, ...)             # ページキャッシュに書くだけ
  fsync(fd)                  # data.tmp のデータ＋メタデータを永続化
  close(fd)
  rename("data.tmp","data")  # 同一FS内なら原子的に差し替え
  dfd = open(親ディレクトリ)
  fsync(dfd)                 # rename（ディレクトリ更新）を永続化

この「一時ファイルへ書く → fsync → 原子的 rename → ディレクトリ fsync」は、アプリ側で WAL と同じ原理を再現しています。rename の原子性が「コミットレコード」に相当し、それ以前の状態は不完全として無視できます。

書き込み順序とバリア：保証の土台

これらすべての保証は、指定した順序でストレージに永続化されること を前提にしています。ところが現代のディスクや SSD は内部に揮発キャッシュを持ち、OS が出した順とは違う順で媒体へ書くことがあります（リオーダリング）。これを放置すると、コミットレコードがデータ本体より先に永続化され、ジャーナルの原子性が崩れます。

そこで FS は FLUSH（デバイスキャッシュ全体を媒体へ追い出す）と FUA（Force Unit Access、その書き込みだけ媒体へ直接） をコミットの前後に発行し、ハードウェア層に順序を強制します。fsync が「確実に永続化」と言えるのは、最終的にこの FLUSH/FUA まで到達させるからです。これが効かなければ「fsync は返ったがデバイスキャッシュ内に留まり、電源断で消えた」事故が起こります。

まとめ

• クラッシュ整合性 は、本来非原子的な複数ブロック更新を、復旧後に「全部反映済み」か「全く反映していない」のどちらかへ収束させ、半端な中間状態を観測させない仕組み。
• ジャーナリング（WAL）・CoW・ログ構造 は表面上別物だが、その場上書きを避け、単一の原子的書き込みで新旧を切り替え、それ以前に依存物の永続化を強制する、という共通原理を持つ。
• fsync はデータ＋メタデータ、fdatasync は読み出しに必須なメタデータのみ、O_SYNC/O_DSYNC は各 write を同期化する。新規ファイルでは親ディレクトリの fsync も必要。
• すべての保証は FLUSH/FUA によるデバイスキャッシュのフラッシュと書き込み順序（バリア） が土台であり、これが崩れると上層のログやCoWの原子性ごと破綻する。基礎は ファイルシステム も参照してください。