コンピューターサイエンス：アルゴリズム / OS / ネットワーク / DB
ジャーナリングと耐障害性
ジャーナリングと耐障害性
このレッスンで分かること
- ジャーナリングは「ファイルシステム操作を 書き込みログ に先に記録する」仕組みで、突然の電源断や OS クラッシュからデータを守ります
- データだけを守る方式と、メタデータも守る方式があり、性能と安全性が変わります
- コピーオンライト方式（btrfs、ZFS、APFS）はジャーナリングと違うアプローチで同じ問題に挑戦しています
ジャーナリングと耐障害性 とは
ジャーナリングと耐障害性。本レッスンでは、ジャーナリングと耐障害性 の基本から実際の使いどころまでを整理し、現場で迷わず使える形に落とし込みます。
なぜジャーナリングが必要か
ファイル 1 つを書き込むとき、OS は複数のディスク操作を順番に行います。
- データブロックに中身を書く
- i-node にサイズと更新日時を書く
- ブロックビットマップで該当領域を「使用中」に
- ディレクトリエントリを追加
これらを行っている 途中で電源が落ちる と、ディスクが矛盾した状態に陥ります。例えば「データは書かれたけどディレクトリエントリに登録されていない」、または「ファイルとして登録されたけどブロックが空き扱いのまま」など。最悪の場合、ファイルシステム全体が壊れます。
ジャーナリングは「やりたい操作の一覧をまず ログ領域 に書き、確実に届いたことを確認してから本体に反映する」二段書きでこれを防ぎます。
ジャーナル動作の流れ
クラッシュからの復旧時は、ジャーナル領域に コミット済み のエントリだけを再走させることで、本体を一貫した状態に戻せます。
ジャーナリングのレベル
ext4 では下記の 3 モードがあります。
| モード | データ保護 | メタデータ保護 | 性能 |
|---|---|---|---|
| journal | あり | あり | 遅い（2 重書き） |
| ordered | データ先 + メタデータをジャーナル | あり | 標準 |
| writeback | データは無保証 | あり | 速い |
デフォルトは ordered で、データはジャーナル前に書き、メタデータだけログするバランス型です。
コピーオンライト方式
btrfs、ZFS、APFS は コピーオンライト（CoW） を採用しています。書き換えるとき元の場所を更新せず、新しい場所に書いて、最後にメタデータ（ルート）のポインタだけ差し替えます。これにより「途中で電源断 → 古い状態か新しい状態のどちらか」のアトミックな世界が常に保たれます。
C を書き換える場合、A と B は共有、C だけ新しく作る → 最後にルートを差し替える、という流れです。スナップショットがほぼ無コストで取れる副産物もあります。
fsync と耐障害性
ファイル書き込みは OS のページキャッシュに溜まってから遅延書き出しされます。アプリが本当にディスクに焼き付けたいなら 明示的に fsync を呼ぶ 必要があります。
c
write(fd, buf, n);
fsync(fd); // ディスクに焼き付くまでブロックデータベースの「コミット」が遅いのは、内部で fsync を呼んで耐障害性を担保しているからです。電源断耐性をテストする際は fsync 後の状態だけが永続性を保証 という前提を忘れてはいけません。
トレードオフ
- ジャーナリングは安全ですが書き込みコストが上がります。SSD では遅延の影響が小さく、ほぼ気にする必要はありません
- CoW 方式は信頼性が高い反面、フラグメンテーション（書き換えが続くと断片化）が起きやすい欠点があります
fsyncは重い操作で、頻発するとアプリが目に見えて遅くなります。複数の書き込みをまとめてから 1 回呼ぶ設計が定石です
よくある誤解
- 「ジャーナリングならクラッシュしてもデータが完全に守られる」は誤りで、デフォルトモードでは メタデータの整合性 が守られるだけです。アプリ側で
fsyncを呼んでいなければ、最後の数秒のデータは消えます - 「SSD なら電源断でも安全」も誤解で、書き込みバッファの電源持続コンデンサがない安価な SSD は内部のメタデータが壊れる可能性があります
やってみよう
ターミナル
dmesg | grep -i "journal\|ext4\|recovered"過去にクラッシュした履歴があれば、recovering journal のログが残っていることがあります。Linux の起動時にファイルシステム自動修復が走った痕跡です。
よくある質問
Q. ext4 のデフォルトジャーナリングモードは何ですか？
A. ordered モードです。データをジャーナル書き込みの前に先にディスクへ書き出し、その後でメタデータをジャーナルに記録します。データ自体はジャーナルに入れないため journal モードより高速で、かつメタデータの整合性は保てるバランス型です。
Q. fsync を呼ばないとどうなりますか？
A. OS のページキャッシュに溜まったデータが遅延書き出しされる前に電源断やクラッシュが起きると、最後の数秒分の書き込みが失われます。ジャーナリングが守るのはファイルシステムのメタデータ整合性であり、アプリのデータを永続化するには fsync を明示的に呼ぶ必要があります。
Q. CoW（コピーオンライト）とジャーナリング、どちらを選ぶべきですか？
A. 用途と環境によります。btrfs や ZFS の CoW はスナップショットが容易で整合性が高い反面、書き換えが多いワークロードではフラグメンテーションが起きやすくなります。ジャーナリングは枯れた実績と低オーバーヘッドが強みで、ext4 はほとんどの Linux 環境でデフォルト採用されています。SSD 主体なら CoW のデメリットが小さくなるため、btrfs や ZFS も現実的な選択肢です。
次のレッスン
次は パーミッションと所有者 で、ファイルのパーミッションと所有者の仕組みを学びます。
事前確認 — 進む前に次の 3 つができることを確認しましょう。
- ジャーナリング の要点を自分の言葉で説明できる
- このレッスンの最小コード (または操作手順) を見ずに書ける
- 練習問題やクイズで間違えた箇所を読み直して理解した
理解度チェック (30 秒)
Q. ジャーナリング とは何か、1 文で説明してください。
A. 本文の「このレッスンで分かること」または冒頭の説明文を見直し、自分の言葉で要約できれば OK。詰まったら本レッスンの最初の H2 セクションを読み返してみましょう。
関連レッスン