ファイルシステムの実装：レイアウト、ジャーナル、COW およびリカバリ

ファイルシステムが正常にマウントできるからといって、クラッシュ前の2回の業務用書き込みが同時に保持されていることを意味するわけではありません。以下では、⁠ブロックレイアウト、構造復旧、データチェックサム、履歴復元をそれぞれ詳しく解説し、1つの特徴ですべての保証を概括しないようにします。

1. extent は連続範囲のマッピングであり、定数時間の魔法ではない

ブロックサイズを 4 KiB とし、extent が「論理ブロック 100 からの 8 ブロックが、物理ブロック 900 からの 8 ブロックに対応する」と記述しているとします。102 × 4096 + 17 にアクセスする場合：

物理ブロック番号は依然としてファイルシステム層に属しており、その下にはボリュームマネージャーやデバイスマッピングが存在する可能性があります。

extent が節約するのは、連続領域のマッピング記録です。8つのブロックは、ブロックごとにポインタを持つ代わりに、1つの記録で記述できます。間接ブロックの設計は、N番目のブロックを検索する際に N 個のポインタを線形スキャンするわけではありません。インデックスを通じて段階的に位置を特定できます。extent の木検索のコストも、木の高さと断片化の数に依存しており、「間接ブロックは O(N)、extent は O(1)」と概括することはできません。

ext4 の inode には、extent 木のルートを受け入れる 60 バイトの領域があります。12 バイトのヘッダーの後に、4つの 12 バイトの記録を格納できます。木の高さが 0 の場合、これらはリーフの extent です。木が大きくなると、ルートにはインデックスが格納され、「最初の4セグメントのデータは常に inode の中に直接残る」とは言えなくなります。ee_len には、初期化済み/未初期化（unwritten）のエンコーディングルールがあり、単なる解釈不能な通常の長さではありません。ext4 inode とブロックマッピング を参照してください。

3つの「まだ書き込まれていない」状態、占有関係はそれぞれ異なる

遅延割り当ては集約に有利ですが、その後の書き戻しで割り当てに失敗する可能性があります。プリアルLOCATION も、将来のメタデータ更新や COW におけるスペース不足を絶対に回避するものではありません。

以下では、「読み取るとゼロになる」と「物理ブロックがすでに割り当てられている」を分けて図解します。ホール、unwritten、通常、共有範囲それぞれに書き込みを行い、位置や他のファイルの内容が同時に変わるかどうかを観察します。

2. ext4：ジャーナルは何を保護し、ordered は何を追加するか

JBD2 は一連のメタデータ変更をジャーナルに書き込み、有効なコミットレコードを確立した後、後で最終位置へのチェックポイントを実行できます。クラッシュ復旧では有効なトランザクションを再生し、ディレクトリ、割り当てビットマップ、inode などの関連する変更が、一貫性のない中間状態で停止しないようにします。コミットはジャーナルトランザクションが復元可能な境界であり、チェックポイントは最終位置への進行です。これらは同じ瞬間ではありません。

例えば、アプリケーションが同じファイルの2つの領域を連続して上書きする場合、ファイルシステムメタデータが完全に合法であっても、クラッシュ後に data=ordered だけで両方が同時に新バージョンであると見なすべきではありません。ジャーナル整合性はファイルシステムが復元可能な構造に関心があり、アプリケーションの1つの業務トランザクションには、独自の原子性更新プロトコルが必要です。ext4 ジャーナルの説明 を参照してください。

遅延割り当てとバックグラウンド書き戻しは、メモリ内に永続化されていないデータの集合を拡大できますが、「クラッシュ時にダーティページが消失する」現象は遅延割り当て固有のものではありません。ここで変更を保持する必要があるかどうかは、fsync、同期オープンなどのインターフェースで表現すべきであり、バックグラウンドで数秒後にフラッシュされるかどうかを推測すべきではありません。

3. XFS：割り当ての並列性を AG に分散させる

AG は Allocation Group（割り当てグループ） です。各グループはローカルな空きスペースと inode 割り当て情報を管理し、すべての割り当てリクエストが1つのグローバル構造に殺到する圧力を軽減します。ファイルのデータは複数の AG に分散可能であり、AG は各 CPU が固定で独占するパーティションではありません。ジャーナル、同一 inode の並列変更、デバイススループットは依然として共有ボトルネックとなる可能性があります。

XFS は異なるインデックスで異なる質問に答えます。アドレスとサイズで整理された空き空間インデックスは適切な領域を見つけるために使用されます。inode 割り当て木は inode チャンクとその使用状況を記述します。ファイル自身の extent マッピングは論理オフセットを物理領域にマッピングします。inode 割り当て木を単純に「各リーフが完全な inode を格納している」と記述することはできません。小規模な記録は埋め込み形式で存在する可能性があり、必ずしも外部の B+tree を毎回トラバースするわけではありません。

共有 extent：独立したファイルでも内容は共有可能

reflink をサポートするファイルシステムでは、2つの異なる inode がデータ extent を共有でき、共有範囲の修正時に COW が実行されます。コピーはハードリンクではありません。両方の名前とメタデータは独立しており、その後で片方を修正しても、ハードリンクのセマンティクスに従ってもう片方が変更されることはありません。XFS reflink と Btrfs はどちらも範囲単位で共有および分裂をサポートしており、「extent 単位とファイル全体単位の COW」で二者を区別することはできません。

最新の XFS の自己記述型メタデータには、チェックサム、所有オブジェクト、位置情報などが含まれており、破損や誤った位置への書き込みを検出できます。これは、通常のユーザーファイルデータにも同様のエンドツーエンドのチェックサムがあることを意味するものではありません。XFS メタデータ完全性設計 を参照してください。

4. Btrfs：参照パスの更新

デフォルトの COW データパスでは、変更を新しい位置に書き込み、関連するメタデータ参照を更新します。トランザクションのコミットには、書き込み順序とルートの有効性要件を満たす必要があります。「各ポインタが個別に原子書き込みされるため、どの中間状態でも安全である」というわけではありません。旧 extent は、現在の木、スナップショット、その他の参照がそれを必要としなくなった場合にのみ回収できます。

スナップショットは通常、既存の構造とデータを共有して作成され、サブボリューム全体の内容をコピーする必要はありませんが、すべての規模と負荷で厳密に O(1) であるわけではありません。その後、旧バージョンが保持されるにつれてスペースが徐々に消費されます。ファイルを削除した後でも、スナップショットはそれが占有していたブロックを保持し続ける可能性があります。サブボリュームには独自のファイルツリーがあり、個別にマウントできますが、独立した物理ボリュームではなく、自動的に mount namespace 分離を形成するわけではありません。ネストされたサブボリュームの内容は、親/子ボリュームのスナップショットに再帰的に含まれません。

COW は、小さな修正でも常に元の完全な大 extent をコピーする必要はありません。実際には、実装や圧縮ユニットなどのルールに従って分割/書き換えが行われます。圧縮、断片化、共有の程度は書き込み増幅に影響します。NOCOW などの設定を有効にすると、データチェックサムと共有書き込みの制限が異なります。Btrfs には fsync を加速するための tree log があるため、「COW ファイルシステムにはジャーナルが不要である」という主張も成立しません。Btrfs 機能の説明 および サブボリュームのセマンティクス を参照してください。

検出、修復、履歴復元は3つの異なる能力

したがって、「2枚のディスク」「チェックサムあり」「スナップショットあり」は異なる条件であり、1つで他の条件を代替することはできません。

Btrfs のデータチェックサムアルゴリズムは設定可能であり、すべてのファイルを固定 CRC32C に書き込むべきではありません。データとメタデータのプロファイルも異なる場合があります。「2枚のディスクがある」だけでは、実際のプロファイル、デバイスのエラー、残りの利用可能なコピー数をチェックする代替にはなりません。

5. bcachefs：階層配置と回収も設計の重点

bcachefs は、extent マッピング、B-tree、ジャーナル、チェックサム、圧縮、マルチデバイス管理を組み合わせます。高速デバイスは書き込みまたはキャッシュを受け持ち、低速デバイスはバックグラウンドでのデータ移行データを保持します。これには、配置ターゲット、コピー数、バックグラウンド移行、スペース回収の間の調整が含まれます。copygc は、まだ有効なデータを回収対象領域から移動させるため、ユーザーの書き込み量とデバイスの総書き込み量は異なる可能性があります。

ジャーナルは削除できる装飾的なオプションではなく、「COW が主でジャーナルはオプション」という記述は、そのリカバリプロトコルを説明するものではありません。比較する際は、永続コミットの条件、データとメタデータのコピーポリシー、デバイス故障後の復旧パスを見るべきであり、プロジェクトの宣伝目標を証明済みのパフォーマンス結論として記述すべきではありません。

バージョンとデプロイメントの境界

バージョン確認：2026-09-08。 bcachefs は Linux 6.7 でメインラインに入りましたが、現在公式には 6.18 以降メインラインカーネルから配布されなくなり、ツリー外 DKMS モジュールに切り替わりました。デプロイメントとアップグレード時には、モジュール、ツール、対象カーネル、ディスクフォーマットの互換性を同時に確認する必要があり、「6.7 以降のカーネルに付属」とだけ記述することはできません。bcachefs 公式説明 および 公式ソースリポジトリ を参照してください。

6. 能力の境界で比較し、固定の優勝者を出さない

容量の上限は、ブロックサイズ、フォーマット特性、カーネル実装、ツールバージョンに依存し、フォーマットの理論的なビット数をそのままユーザー利用可能な上限として記述すべきではありません。パフォーマンス比較では、データセット、並列性、同期頻度、空き容量、スナップショット状態を固定すべきです。短時間のバッファ書き込みはメモリへの吸収速度しか測定できないため、デバイスの持続能力を説明することはできません。

以下の純粋な計算例は、デバイスを修正せずに論理範囲のマッピングをチェックします：

extents = [(100, 8, 900), (108, 4, 3000)]  # 論理起点、長さ、物理起点

def locate(byte_offset, block_size=4096):
    if byte_offset < 0:
        raise ValueError("negative offset")
    logical, within = divmod(byte_offset, block_size)
    for start, count, physical in extents:
        if start <= logical < start + count:
            return physical + logical - start, within
    return None  # このモデルではホールを表す；unwritten/delalloc はモデル化していない

assert locate(102 * 4096 + 17) == (902, 17)
assert locate(108 * 4096) == (3000, 0)
assert locate(112 * 4096) is None
print("extent 範囲と境界：通過")

永続更新のアプリケーションプロトコルは VFS 応用 を参照、ストレージプール、TXG、ZIL は ZFS を参照してください。