BtrfsとXFSのパフォーマンス比較！スナップショットやデータベース運用に向いているのはどっち？

BtrfsとXFS。
どちらもLinuxカーネルが標準でサポートする主要なファイルシステムですが、その設計思想と得意分野は明確に異なります。
特に「スナップショットを活用したバックアップ運用」と「高負荷なデータベースのバックエンド」という二つのユースケースでは、選択を誤るとパフォーマンスのボトルネックだけでなく、運用の柔軟性や障害復旧の手間にも直結します。

そもそもBtrfsは、ZFSを強く意識した次世代型ファイルシステムです。
コピーオンライト（CoW）を基盤に、サブボリュームやスナップショット、データ圧縮、さらにはRAID機能までも内包するオールインワン志向が特徴です。
一方のXFSは、歴史あるエンタープライズ向けジャーナリングFSであり、大容量ファイルの扱いと高スループット性能で定評があります。
特にRed Hat系ディストリビューションでは標準採用され、実績の豊富さが際立ちます。

では、実際のワークロードで両者はどのような差を見せるのでしょうか。
ここでは以下の三つの観点から比較していきます。

ランダム読み書きとシーケンシャルアクセスにおける生のスループットとIOPS
スナップショット取得時および世代管理時のメタデータ操作の重さ
データベース（PostgreSQL／MySQL）のトランザクション処理における応答性とチェックポイント負荷

特に注意したいのは、BtrfsのCoW機能がデータベースのデータファイルに対して逆効果になるケースです。
頻繁な更新が発生する環境では、CoWによる断片化と領域再利用のオーバーヘッドが顕著になり、XFSと比較して最大で30%近いスループット低下を報告するベンチマークも存在します。
ただし、これを回避するために「ノードサイズのチューニング」や「特定ファイルでのCoW無効化」など、実践的な対策が可能な点もBtrfsの魅力です。

逆にスナップショット運用においては、Btrfsが圧倒的に有利です。
瞬間的なスナップショット作成とリストアは、XFSではLVMやdm-snapshotを併用する必要があるのに対し、Btrfsはファイルシステム単体で完結します。
バックアップウインドウがシビアな環境や、頻繁にテスト用ブランチを作る開発現場では、この差は戦略的に大きな意味を持ちます。

比較項目	Btrfs	XFS
スナップショット	ネイティブで高速・世代管理容易	LVM併用が必要で運用が複雑化
データベース向け性能	チューニング次第で実用圏内	デフォルトで安定した高スループット
圧縮機能	オンライン圧縮が標準対応	非対応（別途LVMやファイル単位で対応）
障害復旧の容易さ	修復ツールは進化中だが複雑	xfs_repairが堅牢かつ高速
推奨ワークロード	コンテナ管理・バックアップサーバ	データウェアハウス・分析用DB

では、どちらを選ぶべきか。
データベースの本番運用で迷ったら、まずXFSを選択肢の筆頭に置くのが無難です。
特にIOレイテンシに敏感なサービスでは、余計な予期せぬ挙動を避けられる点が大きい。
一方で、スナップショットを日常的に活用し、かつ圧縮や重複排除によるストレージ効率を重視するならBtrfsに投資する価値があります。
ただし、その場合は必ず最新のカーネルとメンテナンスポリシーを確認してください。

最終的には、実際のハードウェアとワークロードで計測することが唯一の正解です。
しかし、その計測の前提として、それぞれのファイルシステムが「何を最適化しているのか」を理解しておけば、チューニングポイントも自ずと見えてくるはずです。

BtrfsとXFS、どちらを選ぶべきか？　本比較の背景と目的
設計思想の違いがパフォーマンスを分ける　CoWとジャーナリングの基礎
シーケンシャル読み書きとランダムIO　ベンチマーク数値で見る実力差
スナップショット運用の実践比較　取得速度・世代管理・リストア時間
データベースワークロードでの挙動　PostgreSQLとMySQLで検証
Btrfsをデータベースで使う際のチューニングポイント　CoW無効化とノードサイズ
障害復旧とメンテナンス性　fsckや修復ツールの使い勝手を比較
ユースケース別最終推奨　バックアップサーバか分析DBかで分かれる結論
総合まとめ　BtrfsとXFS、それぞれの最適な居場所

BtrfsとXFS、どちらを選ぶべきか？　本比較の背景と目的

Linux環境でファイルシステムを選ぶ際、多くの管理者やエンジニアが一度は直面するのが「BtrfsかXFSか」という選択です。
どちらもカーネルに組み込まれ、実績のあるファイルシステムですが、その内部構造と提供する機能セットは驚くほど異なります。
単純に「どちらが速い」と決めつけられないのは、ワークロードによって有利不利がはっきりと分かれるからです。

本記事では、この二つのファイルシステムを、スナップショット運用とデータベースバックエンドという二つの典型的なユースケースに絞って比較します。
なぜこの二つなのか。
それは、現代のITインフラにおいて、コンテナベースの開発環境やバックアップ戦略、そしてミッションクリティカルなDBサーバは、ほとんど全てのシステムに共通する要素だからです。

まず、押さえておくべき背景を整理しましょう。

Btrfsは「次世代Linuxファイルシステム」として設計され、サブボリュームやスナップショット、圧縮、重複排除、さらにはソフトウェアRAIDのような高度なストレージ機能を内包することを目指しています。いわば「全部入り」のファイルシステムです
XFSは、1990年代から続くエンタープライズ向けのジャーナリングファイルシステムで、大規模なファイルや高スループットなシーケンシャルアクセスに強みを持ちます。Red Hat Enterprise LinuxやCentOSのデフォルトFSとして採用され、安定性と性能で長年にわたり信頼を集めてきました

ここで重要なのは、Btrfsの多機能性は必ずしも全ての場面でメリットにならないという点です。
特に、頻繁なランダム書き込みが発生するデータベースでは、コピーオンライト（CoW）機構が予期せぬオーバーヘッドを生むことが知られています。
一方、XFSはシンプルで堅牢な設計ゆえに、チューニングの余地が少ない反面、デフォルトでも安定したパフォーマンスを発揮します。

では、なぜいまだにBtrfsが注目されるのか。
その答えは「運用の柔軟性」にあります。
スナップショットを数秒単位で作成し、過去の状態に瞬時に戻せる機能は、開発環境やテスト自動化、さらにはランサムウェア対策としてのバックアップ戦略において、非常に強力な武器となります。
XFSでもLVMと組み合わせれば同様のことは可能ですが、その運用コストと習得難易度は明らかに異なります。

本比較で特に注力するのは、以下の三つの論点です。

生のIOパフォーマンス（特にランダムアクセスとシーケンシャルアクセスの差）
スナップショット操作がシステム全体に与える影響（取得時・削除時・リストア時）
データベース（PostgreSQL／MySQL）におけるトランザクションスループットとチェックポイント時の挙動

これらの論点を、実際のベンチマーク数値や運用事例を交えながら、客観的に検証していきます。
すべての環境に最適なファイルシステムは存在しませんが、自社のワークロードに「より適している」ファイルシステムを選ぶための指標を提供することが、この記事の最大の目的です。

また、ファイルシステムの選択は、単なる性能比較だけで終わる話ではありません。
障害復旧のしやすさ、運用中のメンテナンス性、カーネルバージョンアップに伴う互換性リスクなど、長期的な視点も考慮する必要があります。
特にBtrfsは開発が活発な反面、カーネルバージョンによって機能や性能特性が変わることも珍しくありません。
その点、XFSは「枯れた技術」としての安心感がありますが、新機能への対応は当然ながら遅めです。

こうしたトレードオフを理解した上で、皆さんのシステムに最適な選択肢を導き出せるよう、本記事では各FSの「得意なシチュエーション」と「苦手なシチュエーション」を明確にしていきます。

まずは次の章で、両ファイルシステムの設計思想の違いを、パフォーマンスに直結する部分に絞って解説します。
そこで、なぜ同じハードウェアでもこれほど挙動が異なるのか、その根幹を掴んでいただければと思います。

設計思想の違いがパフォーマンスを分ける　CoWとジャーナリングの基礎

BtrfsとXFSのパフォーマンス差を語る前に、まずは両者の設計哲学を理解しておく必要があります。
なぜなら、ベンチマーク数値だけを見ても「なぜそうなるのか」が分からなければ、適切なチューニングや障害時の原因特定が困難になるからです。
ここでは、それぞれのファイルシステムが採用する核心的な仕組みを、パフォーマンスに直結する観点から解説します。

Btrfsの根幹はコピーオンライト（CoW）

Btrfsの最大の特徴は、すべての書き込みをコピーオンライト方式で処理する点にあります。
これは、既存のデータブロックを上書きするのではなく、変更対象のデータを新しい場所にコピーしてから書き込み、最終的に参照先を切り替えるという動作です。
この仕組みにより、書き込み中のクラッシュでもデータの整合性が保たれやすく、スナップショットも一瞬で作成できるという大きなメリットがあります。

ただし、このCoWには代償も伴います。

ランダム書き込みが頻発するワークロードでは、断片化が進行しやすく、読み取り時のシーク時間が増大する
空き領域が断片化すると、書き込み時に新たな領域を確保するためのオーバーヘッドが無視できなくなる
スナップショットを多数保持すると、メタデータの管理コストが非線形に増加するケースがある

つまり、Btrfsは「一貫性とバージョン管理」を最優先した設計であり、その代償としてランダム書き込み性能が時に不安定になる傾向があるわけです。
特にデータベースのように、同じファイル内の異なるオフセットに頻繁に書き込むアプリケーションでは、この影響が顕著に現れます。

XFSが重視するのはジャーナリングとアロケーション効率

一方、XFSはジャーナリングを基盤としながらも、書き込みそのものは「インプレース更新」を基本とします。
つまり、データブロックを直接上書きする方式です。
これにより、CoWのような断片化リスクが低く、特に大容量ファイルの連続書き込みでは高いスループットを維持しやすいという特性を持ちます。

XFSのもう一つの強みは、アロケーショングループと呼ばれる並列化構造です。
ストレージ領域を複数のグループに分割し、それぞれが独立して領域管理を行うことで、マルチスレッド環境での書き込み競合を緩和しています。
この設計は、多数のプロセスが同時にファイルアクセスを行うデータベースサーバやレンダリングファームと非常に相性が良いのです。

ただし、XFSにも弱点はあります。
インプレース更新ゆえに、書き込み中のクラッシュでは古いデータと新しいデータが混在する可能性があり、そのリカバリにはジャーナルを頼るしかありません。
また、スナップショットのようなバージョン管理機能は標準で持たないため、LVMなどの別レイヤと組み合わせる必要が生じます。

両者の違いを表で整理する

ここで、両ファイルシステムの特徴をパフォーマンス関連の観点から表にまとめてみましょう。

比較項目	Btrfs（CoW方式）	XFS（インプレース更新＋ジャーナル）
書き込み特性	新規ブロックへコピー後、参照切替	既存ブロックを直接上書き
断片化リスク	ランダム書き込みで高まる	比較的低い
スナップショット	ネイティブで高速・軽量	非対応（LVM等と連携）
クラッシュ整合性	CoWにより高い整合性を維持	ジャーナルによるリカバリに依存
並列書き込み性能	メタデータ競合が発生しやすい	アロケーショングループで競合緩和

この表を見ると、Btrfsは「安全で柔軟」、XFSは「シンプルで高速」というコントラストが浮かび上がります。
ただし、注意すべきは「Btrfsが常に遅い」わけではないという点です。
例えば、大容量のシーケンシャル書き込みだけを行うバックアップ用途では、CoWのオーバーヘッドは相対的に小さく、圧縮機能との相乗効果でむしろXFSよりも総合的な転送効率が上がることもあります。

パフォーマンスに直結するメタデータの扱い方

もう一つ見逃せないのが、メタデータの更新頻度です。
BtrfsはCoWの性質上、データだけでなくメタデータもコピーされるため、ファイル作成・削除・リネームといった操作が頻発するワークロードでは、ツリー構造の再バランスがCPUリソースを消費します。
一方XFSは、メタデータ更新をジャーナルにまとめてから適用するため、一定のバッチ処理が効きやすく、多数の小ファイルを扱う場合でも比較的安定した応答性を示します。

ただし、ここで強調しておきたいのは、最新のカーネルにおけるBtrfsは大幅に改善が進んでいるという事実です。
特にLinux 5.x以降では、断片化を抑制する自動デフラグ機能や、特定ファイル単位でCoWを無効化するオプション（nodatacow）が実装されており、データベース向けのチューニングも現実的な範囲に収まりつつあります。

結局のところ、設計思想の違いは「トレードオフの違い」に他なりません。
Btrfsは機能豊富であるがゆえに、その恩恵を受けられるワークロードと、オーバーヘッドが災いするワークロードがはっきりと分かれます。
XFSはその逆で、特化した機能こそ少ないものの、幅広いシナリオで平均点が高いと言えるでしょう。

次の章では、この設計差が実際のベンチマーク数値にどう現れるのかを、シーケンシャルとランダムIOそれぞれのケースで具体的に見ていきます。

シーケンシャル読み書きとランダムIO　ベンチマーク数値で見る実力差

設計思想の違いは、実測値に明確な形で現れます。
ここでは、シーケンシャルアクセスとランダムアクセスという二つの基本ワークロードに分け、実際のベンチマークデータを基にBtrfsとXFSの実力差を検証します。
使用するデータは、PhoronixやIEEEの学術論文、そして実環境に近いFIOテストから抽出したものを中心に据えています。

シーケンシャル読み書きではXFSが安定したリードを保持

大容量ファイルの連続読み書き、例えば動画編集やバックアップストリーム、データウェアハウスのフルテーブルスキャンなどでは、XFSが非常に高いスループットを発揮します。
Linux 6.15カーネルでのFIOシーケンシャルリードテストでは、XFSとF2FSが最上位に位置し、Btrfsは中堅どころという結果が出ています。

実際のユーザーによる計測では、ddコマンドを用いた1MBブロックの連続書き込みで、XFSが約3.1GB/sを記録したのに対し、Btrfsは約1.5GB/sに留まったという報告もあります。
この差は、XFSのアロケーショングループ構造が大規模な連続領域の確保を効率化できるのに対し、BtrfsのCoWは書き込みごとに新たなブロックを割り当てるオーバーヘッドを生むためです。

ただし、Btrfsもシーケンシャルリードでは好成績を残すケースがあります。
特にSSD上のシーケンシャルリードでは、BtrfsがXFSを凌ぐスループット（2,626 MB/s）を記録したという学術報告も存在します。
これは、Btrfsのチェックサム検証や圧縮読み取り時のキャッシュヒットが功を奏した可能性があります。
つまり、シーケンシャルライトではXFSが安定して速く、シーケンシャルリードでは環境やカーネルバージョンによって優劣が入れ替わると見ておくとよいでしょう。

ランダムIOではXFSが圧倒、BtrfsはCoWの代償を負う

本領が発揮されるのがランダムアクセス、特にランダムライトの領域です。
複数の研究で一貫しているのは、Btrfsのランダムライト性能がXFSやEXT4と比較して顕著に低いという点です。

ある仮想環境下でのベンチマークでは、4KランダムライトのIOPSがXFSで約32,011、EXT4で約36,996だったのに対し、Btrfsは約26,024にとどまりました。
これはEXT4を基準にすると約30%もの性能低下に相当します。
この原因は明らかで、CoWがランダムな書き込みごとに新規ブロックの確保とB-tree構造の更新を強いるからです。
ファイルシステムのメタデータツリーが頻繁に再バランスされ、その分だけCPUリソースとI/Oレイテンシが消費されます。

ランダムリードに関しても、Btrfsはデフォルト設定ではXFSやF2FSよりも遅い傾向が確認されています。
特に4Kランダムリードでは、XFSが優れたスケーラビリティを見せるのに対し、Btrfsはメタデータ検索の階層が深くなる分、応答にばらつきが出やすいのです。

ワークロード別に見る優先順位

以上の数値から、下記のような整理ができます。

シーケンシャルライトが主体（バックアップの書き込み、大容量ログの保存）なら、XFSを選ぶのが無難です。デフォルトで高いスループットを維持し、断片化のリスクも低い
シーケンシャルリードが主体（メディアストリーミング、データ分析のスキャン）なら、Btrfsも有力な選択肢です。カーネルバージョンによってはXFSを上回る結果も出ています
ランダムライトが頻発するデータベースやVMイメージでは、XFSが明確に有利です。BtrfsのCoWはここで最大の弱点を露呈します

ただし、Btrfsのランダムライト性能はカーネルバージョンとともに改善が続いています。
Linux 7.3では、一部のランダムライトシナリオで23%程度の性能向上が確認されており、XFSとの差は確実に縮まりつつあります。
とはいえ、依然として絶対的な数値ではXFSに軍配が上がるため、「現時点で最高の生性能」を求めるのであれば、やはりXFSを推奨せざるを得ません。

次の章では、このランダムライトの弱点がデータベース運用にどう影響するのかを、PostgreSQLとMySQLの実測値を交えて掘り下げていきます。

スナップショット運用の実践比較　取得速度・世代管理・リストア時間

ベンチマークで語られる生のIO性能も重要ですが、実運用においては「運用のしやすさ」が選択を大きく左右します。
特にスナップショット機能は、BtrfsがXFSに対して持つ最も明確なアドバンテージの一つです。
ここでは、スナップショットの取得速度、世代管理の手間、そしてリストア時間という三つの実践的指標に絞って、両ファイルシステムを比較していきます。

Btrfsのスナップショットは「ほぼゼロコスト」で取得できる

Btrfsのスナップショットは、サブボリューム単位で作成され、その瞬間のメタデータ参照をコピーするだけの軽量操作です。
実際のデータブロックは一切コピーされず、CoWによって変更が発生した部分だけが新たに書き込まれます。
そのため、スナップショット取得時のシステム負荷は極めて低く、数十GBのデータが存在するサブボリュームでも、取得時間は1秒未満が普通です。

この特性は、自動バックアップやテスト環境の使い捨て作成に理想的な条件を提供します。
例えば、cronで5分おきにスナップショットを取得しても、ディスクI/Oへの影響はほぼ無視できるレベルです。
また、スナップショット自体もサブボリュームとしてマウント可能なため、過去の状態にアクセスして特定ファイルだけを取り出すといった細かな作業もコマンド一発で済みます。

世代管理に関しても、Btrfsはbtrfs subvolume listやbtrfs subvolume deleteによるシンプルな操作体系を備えており、スクリプトによる自動ローテーションも容易です。
スナップショットの保持数が増えても、削除はメタデータの参照カウントを減らすだけの処理であり、実際のデータブロックは他のスナップショットから参照されている限り残るため、安全かつ効率的です。

XFS＋LVMでは運用設計が複雑化する

対照的に、XFS自体にはスナップショット機能がありません。
そのため、同等の運用を実現するにはLVM（Logical Volume Manager）のスナップショット機能を併用するのが一般的です。
LVMスナップショットは、書き込み時にオリジナルブロックを退避領域（COWテーブル）に保存する方式で、Btrfsと似たCoWの考え方を持ちますが、その実装はボリューム単位であり、ファイルシステム内部の細かい制御は効きません。

ここで問題になるのが、以下の運用上の制約です。

スナップショット作成時に、あらかじめ退避領域（スナップショット用の論理ボリューム）を確保しておく必要があり、容量設計が煩雑になる
スナップショットの数が増えると、退避領域の消費が急増し、領域不足によるスナップショットの自動破棄やパフォーマンス低下が発生するリスクがある
スナップショット取得中は、元のボリュームの書き込み性能が低下する（退避領域への書き込みが競合するため）
リストア時は、スナップショットボリュームをアクティブにしてマウントするか、元のボリュームにマージする操作が必要で、その間サービスを停止せざるを得ないケースが多い

つまり、XFS＋LVMでもスナップショット運用は不可能ではありませんが、その設計と運用監視にはBtrfsと比較して明らかに多くの工数がかかります。
特に世代管理を自動化しようとすると、LVMのスナップショット数には上限があり、また削除時のパフォーマンスもBtrfsほど滑らかではないため、定期的なメンテナンスが必須です。

リストア時間で比較する「実質的な停止時間」

スナップショットの価値は、取得速度だけでなく「いかに早く過去の状態に戻せるか」にも依存します。
ここで両者を比較してみましょう。

運用フェーズ	Btrfs	XFS＋LVM
スナップショット取得時間	1秒未満（データサイズに依存せず）	数秒〜数分（退避領域の初期化が必要）
スナップショット一覧表示	即時（サブボリュームリスト参照）	lvsコマンドで確認（表示は高速だが冗長）
特定ファイルのリストア	スナップショットをマウントしてcp	スナップショットボリュームをアクティブ化してマウント
ボリューム全体のロールバック	`btrfs subvolume set-default`で即時切替	lvconvert –mergeでマージ。完了まで時間がかかる
スナップショット削除	メタデータ削除のみで即時	退避領域の解放に時間がかかる場合がある

この表からも明らかなように、Btrfsはロールバックそのものが「参照の切り替え」 で完了するため、実質的な停止時間はほぼゼロです。
一方、XFS＋LVMでは、マージ操作中は元のボリュームがオフラインになるか、著しく性能が制限されるため、サービス影響を考慮した計画的運用が不可欠となります。

まとめ：スナップショット運用ならBtrfsに軍配が上がる

スナップショットの取得速度、世代管理の容易さ、リストアに要する時間と停止リスクのいずれを取っても、BtrfsはXFS＋LVM構成を大きく引き離します。
特にDevOpsやCI/CD環境のように、短いサイクルでテストブランチを作っては捨てるようなワークロードでは、Btrfsの運用効率は圧倒的です。

ただし、ここで注意すべきは、スナップショット運用の恩恵は、それによって生じるランダムライト性能の低下を許容できるかどうかにかかっているという点です。
頻繁にスナップショットを取得しながら、同時にデータベースのような高負荷書き込みを実行する場合、Btrfsは両方の面で苦戦する可能性があります。
そのトレードオフをどう評価するかが、次のデータベース検証のテーマとなります。

データベースワークロードでの挙動　PostgreSQLとMySQLで検証

スナップショット運用で圧倒的なアドバンテージを持つBtrfsですが、データベースワークロードにおいてはその評価が一転します。
ここでは、PostgreSQLとMySQL（および互換のMariaDB）を対象に、実際のベンチマークと運用事例を基に両ファイルシステムの挙動を検証します。
結論から言えば、現時点でもデータベースのバックエンドにはXFSが推奨されるケースが圧倒的に多いです。

XFSがデフォルトで高スループットを発揮する理由

XFSがデータベースワークロードで好成績を収める理由は、設計思想の章で触れたインプレース更新とアロケーショングループにあります。
データベースエンジンは独自にバッファプールやWAL（Write-Ahead Log）を持ち、ファイルシステムに対して頻繁なランダム書き込みを発行します。
XFSはこの種のアクセスパターンにおいて、一貫した低レイテンシと高スループットを両立できるのです。

Linux 7.0環境でのMariaDB（mysql-slap）ベンチマークでは、XFSがEXT4やF2FSとほぼ互角ながら、総合的に最上位のパフォーマンスを示しました。
また、大規模なエンタープライズストレージのベンチマークでは、XFSがPCIe 5.0アレイ上で55GB/sという驚異的なスループットを達成し、PostgreSQLで30,000 TPS以上を記録した事例も報告されています。

さらに、DuckDBを用いたTPC-H Parquetワークロードでは、XFSが最も低いレイテンシを記録しており、分析用途のデータベースでも優位性が確認されています。
つまり、トランザクション処理（OLTP）だけでなく、分析処理（OLAP）においてもXFSは安定した強さを発揮するわけです。

Btrfsがデータベースで苦戦する根本原因

一方、Btrfsがデータベースワークロードでパフォーマンスを発揮しにくい理由は、前章までに解説したコピーオンライト（CoW）構造に集約されます。
データベースは内部でデータファイルを頻繁に更新しますが、Btrfsはそのたびに新規ブロックを確保して書き込み、メタデータツリーを更新します。

この動作が、以下の悪循環を生みます。

データベースのWAL書き込みとBtrfsのCoWが二重に書き込みを発生させ、実効的なI/O量が増大する
ランダム書き込みによる断片化が進行し、読み取り性能も経時的に低下する
チェックポイントやバキュームといったデータベース側のメンテナンス処理と、Btrfs側のメタデータ更新が競合する

実際に、MySQL（InnoDB）を用いたテーブル作成と外部キー制約の設定テストでは、BtrfsがXFSと比較して約62%も処理時間が増加したという計測結果があります（Btrfs：53.0秒、XFS：29.2秒）
また、同様の環境でデータ挿入テストを行った場合も、BtrfsはXFSに対して約63%の時間増加（Btrfs：134.3秒、XFS：82.6秒）を示しています。

実運用で考慮すべき追加の論点

パフォーマンス以外にも、データベース運用では以下の点を考慮する必要があります。

障害復旧の確実性：XFSのxfs_repairは大規模ボリュームでも高速かつ確実に動作しますが、Btrfsの修復ツールは複雑で、高度な知識を要します
カーネルバージョン依存性：Btrfsはカーネルアップデートによる性能変動が大きく、本番環境では事前検証が必須です
チューニングの難易度：Btrfsでデータベースを運用するには、nodatacowオプションや圧縮設定などの細かな調整が求められますが、XFSはデフォルトで実用的な性能が出ます

以上を総合すると、一般的なPostgreSQLやMySQL／MariaDBの本番運用では、現時点でもXFSを第一選択とするのが賢明です。
Btrfsの先進機能に魅力を感じる場合でも、まずはXFSで安定した基盤を構築し、その上で特定のワークロードに限ってBtrfsを試験導入するという段階的アプローチをお勧めします。

Btrfsをデータベースで使う際のチューニングポイント　CoW無効化とノードサイズ

Btrfsのマウントオプションとチューニングパラメータが記された設定ファイルの画面

前章では、Btrfsがデータベースワークロードにおいてデフォルト状態でXFSに劣後する傾向を確認しました。
しかし、それで「Btrfsはデータベースに使えない」と断じるのは早計です。
実際には、適切なチューニングを施すことで、その差を劇的に縮めることが可能です。
ここでは、データベース運用時にBtrfsで実施すべき主要なチューニング項目を、実践的な観点から解説します。

最も効果的な一手：特定ファイルのCoWを無効化する

Btrfsがデータベースで苦戦する最大の要因はコピーオンライトです。
そこで、データベースのデータファイルやWALログが格納されるディレクトリやファイルに対して、CoWを無効化するのが最も直接的かつ効果的な対策となります。

具体的には、ファイル作成時にchattr +C属性を付与するか、マウントオプションでnodatacowを指定します。
ただし、ディレクトリにchattr +Cを設定する場合、その時点で存在する既存ファイルには反映されない点に注意が必要です。
新規作成ファイルのみが対象となるため、運用開始前にデータディレクトリを空にしてから属性を設定するか、ファイル単位で個別に設定することをお勧めします。

CoWを無効化することで、以下の効果が期待できます。

ランダムライト時の新規ブロック確保オーバーヘッドが排除され、IOPSが向上する
断片化の進行が大幅に抑制され、経時的な読み取り性能の劣化が軽減される
データベースのチェックポイントやバキューム処理がファイルシステムと競合しにくくなる

ただし、この設定はスナップショット機能とのトレードオフを含みます。
CoW無効化領域のファイルは、スナップショットを取得しても以前の状態を保持できず、実質的にBtrfsのバージョン管理機能の恩恵を受けられなくなります。
そのため、データベースデータ自体はCoW無効化し、バックアップは別途論理バックアップやレプリケーションで賄う運用が基本です。

ノードサイズとセクターサイズの最適化

次に重要なのが、Btrfsのノードサイズ（ツリー構造のブロックサイズ）と、ストレージの物理セクターサイズの整合性です。
デフォルトでは16KBのノードサイズが使用されますが、データベースのページサイズ（多くの場合8KBまたは16KB）と一致させることで、メタデータ操作の効率が向上します。

具体的には、mkfs.btrfs -n 16384（16KB） を指定するのが一般的な推奨値です。
PostgreSQLのページサイズが8KBの環境では、むしろ-n 8192を選択するケースもありますが、その場合はメタデータのオーバーヘッドが増えるため、実際のワークロードで計測することをお勧めします。

また、SSDを使用する場合は、-s（セクターサイズ）オプションでデバイスの物理セクターサイズ（通常は4KB）を正しく認識させることも忘れてはいけません。
デフォルトでは自動検出されますが、古いカーネルでは誤認識することがあるため、mkfs.btrfs -s 4096を明示するのが安全です。

マウントオプションで動作特性を調整する

ファイルシステムの動作は、マウントオプションによって大きく変わります。
データベース運用では、以下のオプションを検討するとよいでしょう。

noatime：アクセス時刻の更新を省略し、読み取り時のメタデータ書き込みを抑制します。ほぼ全てのデータベースワークロードで有効です
nodiratime：ディレクトリのアクセス時刻更新を省略します。noatimeと組み合わせるのが一般的
autodefrag：断片化を自動的に解消する機能です。ただし、バックグラウンド処理がI/Oと競合するリスクがあるため、高負荷なOLTP環境では慎重に評価してください
space_cache=v2：空き領域キャッシュの効率を向上させ、領域確保時のレイテンシを低減します。最新カーネルではデフォルトで有効ですが、明示的に指定することをお勧めします

特にcompress=zstd:1 のような圧縮オプションは、データベースには原則として適用しないほうが無難です。
圧縮はCPU負荷を増大させ、ランダムアクセス時に解凍オーバーヘッドがレイテンシに直結します。
ただし、ログアーカイブやバックアップ用のボリュームでは非常に有効なので、用途に応じて使い分けてください。

断片化対策の定期メンテナンス

CoWを無効化しても、完全に断片化を防ぐことはできません。
特に、データベースファイルが拡張される際には断片が発生するため、定期的なデフラグ運用を検討する価値があります。
Btrfsではbtrfs filesystem defragコマンドが提供されており、特定のファイルやディレクトリを対象にデフラグを実行できます。

ただし、この操作はファイルシステムの再編成を伴うため、実行中はパフォーマンスが低下します。
ピークタイムを避けて実施するか、レプリカやスレーブノードで実施するなどの計画が必須です。
また、スナップショットが存在する状態でデフラグを行うと、スナップショット間での共有ブロックが解除され、ディスク使用量が急増するリスクがあるため、事前にbtrfs subvolume listでスナップショットの有無を確認してください。

チューニング効果の実測値

これらのチューニングを施したBtrfsは、どの程度XFSに近づけるのでしょうか。
Linux 6.15環境でのMySQL OLTPテストでは、チューニング前のBtrfsがXFS比で約30%遅かったのに対し、CoW無効化＋ノードサイズ最適化を施したBtrfsは、その差を10%未満に縮めたという報告があります。
特にWAL領域のみCoW無効化し、データ領域は圧縮有効にしたハイブリッド構成では、むしろXFSを上回るスループットを記録したケースも存在します。

つまり、Btrfsは「チューニング次第でデータベースでも実用に耐える」 フェーズに達しているのです。
ただし、そのためには十分な検証環境と運用ノウハウが必要であり、XFSのように「設定せずとも速い」という気軽さは期待できません。
本番投入前に必ず、実際のワークロードで計測と調整を繰り返すことを強くお勧めします。

障害復旧とメンテナンス性　fsckや修復ツールの使い勝手を比較

Linuxシェル上でxfs_repairとbtrfs checkを実行しているコンソール画面

ファイルシステムの性能は、順調に稼働しているときの数値だけで評価できるものではありません。
突然の電源断、カーネルパニック、あるいはストレージデバイスの劣化といった障害時に、どれだけ迅速かつ確実にシステムを復旧できるか。
この「メンテナンス性」は、特にエンタープライズ環境では性能と同等、あるいはそれ以上に重要な評価軸です。
BtrfsとXFSでは、この分野における設計思想と実運用の現実が大きく異なります。

XFSのxfs_repairは堅牢かつ高速

XFSが長年にわたりエンタープライズで支持されてきた最大の理由の一つが、xfs_repairの信頼性と速度です。
このツールは、ジャーナルログを再生することで、クラッシュ後の整合性を短時間で復元します。
特に大容量ボリュームにおいて、その性能は圧倒的です。

実際に、Amazon EC2の大規模インスタンス（io1ブロックボリューム）でxfs_repairを実行した事例では、10TBのボリュームに対して約8分で修復を完了したという報告があります。
また、RAID構成上のXFSボリュームで障害が発生したケースでも、xfs_repairはメタデータの整合性を高い精度でチェックし、ほとんどのシナリオでデータロスを最小限に抑えられます。

xfs_repairの優位点は、以下の点に集約されます。

ジャーナル再生が主な処理のため、ファイルシステム全体のスキャンを必要としないケースが多い
修復プロセスが単純で、実行中の進行状況が分かりやすく、操作に迷いが生じにくい
マルチスレッド対応により、現代の多コアCPUを活用した並列処理が可能
障害時に推奨される手順が明確にドキュメント化されており、運用者が迷いにくい

加えて、XFSは「修復中にさらに障害が発生する」という二次災害のリスクが比較的低いことも見逃せません。
これは、メタデータ構造がシンプルであることに起因します。

Btrfsのbtrfs checkは強力だが運用ノウハウを要する

一方、Btrfsにはbtrfs checkという修復ツールが用意されています。
このツールは非常に多機能で、–repairオプションを付与することで、破損したメタデータツリーの再構築や、参照カウントの修正など、高度な修復処理を実行できます。
しかし、その機能の豊富さが逆に運用の複雑さを生んでいます。

最大の注意点は、btrfs check –repairは、実行前に必ず–readonlyモードで事前チェックを行うことが強く推奨される点です。
なぜなら、この修復処理はメタデータ構造を変更するため、誤った判断で実行すると、むしろデータをより深刻に破損させるリスクがあるからです。

また、以下のような運用上の課題も無視できません。

修復に時間がかかる。大規模ボリュームでは数時間から数十時間を要することもある
進行状況が分かりにくく、応答がないように見える時間帯が長く続くため、オペレータが不安になる
修復後のファイルシステムがマウントできるようになっても、一部のデータが欠落している可能性が常に残る
スナップショットが多数存在する環境では、修復処理の対象が膨大になり、さらに複雑化する

つまり、Btrfsの修復ツールは「できることは多いが、正しく使うには深い知識と慎重な判断が不可欠」という性格を持っています。

メンテナンス性に関する実運用の比較表

両者の違いを、日常的なメンテナンス作業の観点から整理してみましょう。

運用シナリオ	XFS（xfs_repair）	Btrfs（btrfs check）
定期チェック（読み取り専用）	xfs_repair -n で数秒〜数分	btrfs check –readonly で数分〜数時間
修復実行時のリスク	低い。ジャーナル再生が中心	中〜高い。–repairは最終手段と認識すべき
修復後のデータ整合性	高い。ほとんどの場合で復旧完了	ケースバイケース。データロスが発生することも
操作マニュアルの充実度	非常に充実。広く知られた手順	ドキュメントはあるが、事例ベースのノウハウが必要
スナップショット環境での挙動	対象外（LVMは別途管理）	メタデータが複雑化し、修復時間が著しく増大

この表からも明らかなように、XFSは「予期せぬ障害からの復旧」をシンプルかつ確実に行える点で、Btrfsを大きくリードしています。
特に、障害対応に不慣れな運用チームや、24時間体制で障害対応者が常駐しない環境では、この差は戦略的に決定的です。

バックアップとの併用戦略が鍵を握る

ただし、どちらのファイルシステムにおいても、修復ツールだけに頼る運用は推奨できません。
重要なのは、ファイルシステムの修復よりも、バックアップからのリストアを優先する判断基準をあらかじめ定義しておくことです。
特にBtrfsでは、修復よりもスナップショットからのロールバックのほうが安全かつ高速なケースが多く、その点は強みとして活用すべきでしょう。

また、Btrfsを使用する場合は、btrfs scrubによる定期的なデータ整合性チェックを組み込み、潜在的なエラーを早期に発見する仕組みを整えておくことが必須です。
一方、XFSではxfs_check（非推奨）に代わり、xfs_scrubが最近のカーネルで利用可能になっており、こちらもオンラインでの健全性確認に役立ちます。

総合評価：保守性を重視するならXFSに分がある

障害復旧とメンテナンス性の観点では、現実的な選択肢としてXFSが一枚上手です。
修復ツールの完成度、速度、そしてオペレータが迷いにくい設計は、長年の実績に裏打ちされています。
Btrfsも着実に改善が進んでいますが、依然として「特殊な状況下では非常に強力だが、日常的な保守には熟練を要する」という位置付けです。

この点を踏まえると、ミッションクリティカルなシステムでは、スナップショット機能の魅力に惹かれても、まずはXFSで基盤を固め、Btrfsは段階的に検証するというアプローチが最もバランスが取れていると言えるでしょう。

ユースケース別最終推奨　バックアップサーバか分析DBかで分かれる結論

ここまで、設計思想、ベンチマーク数値、スナップショット運用、データベースワークロード、チューニング手法、そして障害復旧性と、多角的にBtrfsとXFSを比較してきました。
それぞれの論点で優劣が入れ替わる複雑な結果となりましたが、最終的には「どのようなワークロードで使うか」によって選択は明確に分かれます。
ここでは、代表的なユースケースごとに、実践的な推奨事項をまとめます。

バックアップサーバや開発環境にはBtrfsが強力

スナップショットを武器にしたい環境では、Btrfsが圧倒的な価値を発揮します。
具体的には、以下のようなシナリオが該当します。

複数世代のバックアップを短間隔で取得し、障害時に即座に過去状態へ戻したい
開発者がテスト用にサブボリュームを複製し、使い捨ての環境を頻繁に作成・破棄する
コンテナオーケストレーション（DockerやPodman）のストレージドライバとして活用する
ファイル単位の整合性チェック（チェックサム）を常時行い、データサイレントエラーを検出したい

これらのケースでは、BtrfsのCoWによるオーバーヘッドは相対的に小さく、スナップショット運用の生産性向上がそのコストを十分に上回ります。
また、圧縮機能を有効にすれば、バックアップデータの格納効率が劇的に向上する点も見逃せません。
特にzstd圧縮は、CPU負荷と圧縮率のバランスが優れており、バックアップ専用ボリュームではデフォルトで有効にする価値があります。

本番データベースや高負荷分析ワークロードにはXFS

一方、PostgreSQL、MySQL／MariaDB、あるいはClickHouseやDuckDBを用いた分析処理が主体のシステムでは、現時点でもXFSを第一選択とするのが賢明です。
その理由は以下の通りです。

デフォルトで高スループットかつ低レイテンシを発揮し、チューニングの手間が最小限で済む
ランダムライトの断片化リスクが低く、長期間運用しても性能劣化が穏やか
障害復旧ツールが成熟しており、トラブルシューティングの情報も豊富
カーネルバージョンアップによる性能変動が小さく、予測可能性が高い

特に、トランザクション処理（OLTP）のように1ミリ秒以下の応答が求められるシステムでは、BtrfsのCoWに起因するレイテンシのばらつきは許容できません。
XFSの安定した応答性は、そうしたシビアな要件に最も適合します。

ハイブリッド構成という選択肢

ここで提案したいのが、両方のファイルシステムを用途別に使い分けるハイブリッド構成です。
例えば、データベースサーバにおいて、以下のような割り振りを検討してみてください。

OSブートボリュームとデータベースのデータファイル・WAL領域 → XFS（性能と信頼性を優先）
バックアップ格納用ボリュームやログアーカイブ領域 → Btrfs（圧縮とスナップショットを活用）
テスト環境やステージング環境のデータボリューム → Btrfs（柔軟な複製とロールバックを活かす）

この構成により、各ファイルシステムの長所を引き出しつつ、短所を相互に補完できます。
特に、BtrfsのスナップショットをXFS上のデータベースバックアップ取得に利用する場合、Btrfsボリュームに定期的にrsyncやborgbackupでデータを転送し、その上でスナップショットを取得する戦略は、多くの現場で実績があります。

選択を迷ったときの判断フローチャート

それでもなお迷う方のために、簡易的な判断基準をリスト化しておきます。

データベースが本番で稼働し、サービス停止が許されない → XFSを選ぶ。迷いの余地はない
開発やテスト用途で、頻繁に環境をリセットしたい → Btrfsを選ぶ。スナップショットの恩恵が大きい
ストレージ容量を節約したい（圧縮や重複排除が必須） → Btrfsを選ぶ。ただしCPUリソースに余裕があること
予算が限られていて、運用担当者の習熟度が高くない → XFSを選ぶ。障害対応の容易さがコスト削減に直結する
両方のメリットを取りたい → ハイブリッド構成を採用し、役割を明確に分ける

最後に：バージョンとハードウェアを考慮する

どの選択をするにしても、カーネルバージョンとストレージデバイスの組み合わせが最終的な性能を大きく左右する点を忘れてはなりません。
Btrfsはカーネル5.xから7.xにかけて大幅な性能改善が続いており、最新カーネルでは本記事の数値がすでに古くなっている可能性もあります。
また、NVMe SSDとSATA SSD、さらにはHDDでは、CoWの影響度合いがまったく異なります。

結論として、「今、このハードウェアで、このワークロードを動かす」という具体的な条件を元に、必ず実機ベンチマークを実施することをお勧めします。
本記事はそのための「どの項目を比較すべきか」という羅針盤としてお役立てください。
その上で、運用フェーズや将来の拡張性も見据えた総合判断を下すことが、後悔しないファイルシステム選択への近道です。

総合まとめ　BtrfsとXFS、それぞれの最適な居場所

ここまで約7,000文字にわたり、BtrfsとXFSを設計思想から実運用まで徹底的に比較してきました。
最後に、全ての検証結果を統合し、それぞれのファイルシステムが「最も輝く居場所」を改めて明確にしておきましょう。
読者の皆さんが自らのシステムに最適な選択をするための、確かな判断軸を提供することを目指します。

Btrfsが最適な環境

Btrfsは、機能の豊富さと運用の柔軟性を最大の武器とするファイルシステムです。
以下の条件に多く当てはまる環境では、Btrfsを積極的に採用する価値があります。

スナップショットを日常的に利用し、短時間でのロールバックを要件としている
ストレージ容量を節約するために、圧縮や重複排除を活用したい
サブボリューム単位でデータセットを分離し、個別にバックアップやマウントを行いたい
開発環境やテスト環境のように、データの一貫性よりも運用のターンアラウンドタイムを重視する
データサイレントエラーに対するチェックサム機能をファイルシステムレベルで持ちたい

典型的なユースケースとしては、社内バックアップサーバ、コンテナホストのストレージバックエンド、CI/CDパイプラインのキャッシュボリューム、個人開発用のワークステーションなどが該当します。
これらの環境では、CoWによる性能オーバーヘッドよりも、スナップショットや圧縮がもたらす運用効率の向上が明確に勝ります。

XFSが最適な環境

XFSは、シンプルさと予測可能な高性能が身上です。
以下の条件に該当するシステムでは、迷わずXFSを選択することをお勧めします。

データベース（PostgreSQL、MySQL、MariaDBなど）のデータファイルやWAL領域として使用する
大容量ファイルのシーケンシャル読み書きが主体で、スループットが最重要指標である
ランダム書き込みが頻発し、レイテンシのばらつきを極限まで抑える必要がある
障害発生時の復旧時間を最短化し、運用者の負担を軽減したい
カーネルアップデートによる性能変動を最小限に抑え、長期的な安定運用を図りたい

具体的な導入先としては、本番データベースサーバ、データウェアハウス用の分析サーバ、動画編集やレンダリング向けの高性能ワークステーション、仮想マシンのイメージストアなどが代表的です。
XFSはこれらのワークロードで長年にわたる実績を積んでおり、「設定して終わり」に近い運用が可能です。

両方を使い分けるハイブリッド戦略

すでに前章でも触れましたが、一つのサーバ内で両方のファイルシステムを併用するという選択肢は、非常に現実的で効果的です。
例えば、OSブート領域とデータベース領域にはXFSを、バックアップ領域とログ格納領域にはBtrfsを割り当てることで、それぞれの長所を活かせます。

このアプローチのメリットは、特定のワークロードに最適化されたファイルシステムを選択できるだけでなく、障害ドメインを分離できる点にもあります。
Btrfs領域で問題が発生しても、XFS領域のデータベースには影響が及びにくいという物理的な安心感も得られます。

将来展望と最終的なアドバイス

Btrfsは年々進化を続けており、Linuxカーネル7.x以降では、データベースワークロードでも十分実用に耐える水準に達しつつあります。
特にTigerBeetleのような特殊なDBではXFSを凌ぐ結果も出ており、この流れが続けば、数年後には「Btrfs一択」という時代が来る可能性も否定できません。

しかし、現時点の安定性と予測可能性を重視するなら、やはりXFSが本命です。
新しい機能に飛びつく前に、まずはXFSで堅牢な基盤を築き、その上でBtrfsの検証を並行して進めるという、段階的なアプローチをお勧めします。

最後に、ファイルシステムの選択は「絶対的正解」を求めるものではありません。
大切なのは、自社のワークロード、運用リソース、障害許容度、そして将来の拡張計画を総合的に評価し、その時点での「最適解」を選ぶことです。
本記事がその判断材料として、皆さんの一助となれば幸いです。