ext4・XFS・Btrfs・ZFSをどのワークロードに当てるか――ファイルシステム種別の選定設計

ファイルシステムの選定は、OSインストール時のデフォルトに従うだけでは済まない設計判断です。ext4・XFS・Btrfs・ZFSの四択はそれぞれ「何を守り、何を諦めるか」というトレードオフを内包しており、ワークロードの特性（大量小ファイルかシーケンシャル大容量か）、データ保護要件（スナップショット・自己修復の必要性）、稼働環境（クラウドか物理サーバーか）を軸に絞り込む必要があります。選定ミスはフォーマット変更時の大規模データ移行という高コストな作業に直結するため、構築フェーズで一度確定した選択は後から変えにくい判断です。本記事では各方式のトレードオフを整理し、ワークロード別の選定根拠を設計視点で解説します。

ワークロード特性とファイルシステム特性の対応マトリクス

ランダムIOとシーケンシャルIOで求められる特性の違い

ファイルシステムの内部構造はIOパターンによってパフォーマンスの出し方が大きく変わります。ext4はエクステント方式のアロケーションを採用しており、大容量連続ファイルを扱うシーケンシャルIOに安定した性能を発揮します。XFSはジャーナルとメタデータ管理にBツリー構造を採用しているため、数億ファイル規模の巨大ディレクトリでも検索性能が劣化しにくく、大規模ストレージやハイスループット用途に適しています。ランダム書き込みが主体のOLTPデータベース用途では、Copy-on-Write（CoW）を持つBtrfsやZFSはシーケンシャル書き込みコストが増加する特性を持つため、データベースのデータ領域に直接載せる際には慎重な検討が必要です。

データ保護要件とCoWの選択基準

BtrfsとZFSはいずれもCopy-on-Writeを採用しており、スナップショット・チェックサム・自己修復という機能セットを持ちます。これらは「書き込みコストを払ってデータ整合性を得る」設計思想です。ランダム書き込みが頻発する環境でCoWを有効にすると書き込み増幅によりIOPSが低下します。想定例として、OLTPワークロードでCoW系ファイルシステムをチューニングなしで使用した場合、非CoW系と比べて実効IOPSが25〜40%程度低下するケースが一般的に報告されています。データ保護とスループットのどちらを優先するかを最初に確定しておくと、CoW系／非CoW系の絞り込みが早まります。

可用性要件とレプリケーション設計の起点

ZFSはZPOOLを単位とした冗長化（RAID-Z）をファイルシステム層で内包しており、ソフトウェアRAIDとファイルシステムを一体管理できます。一方ext4・XFSはmdadm等の外部RAIDレイヤーと組み合わせる設計になるため、管理レイヤーが分離します。「障害検知・修復をどのレイヤーに責任を持たせるか」という判断はチームの運用スキルにも依存するため、機能の豊富さだけでなくオペレーション設計も含めて検討してください。ZFSの統合管理は機能として優れていますが、チームが管理コマンド体系に不慣れな場合は習熟コストを設計工数に含める必要があります。

ext4・XFS・Btrfs・ZFS四方式の機能比較表

各方式の主要機能を横断比較します。選定の絞り込み時にご活用ください。チェックサム・自己修復が必要か、スナップショットをOS標準で持ちたいか、RAID統合を一元管理したいか、という三点の要件整理が比較表の読み方の軸になります。

比較項目	ext4	XFS	Btrfs	ZFS（OpenZFS）
ジャーナリング方式	メタデータ＋データ（ordered）	メタデータのみ	CoWによるトランザクション	CoW＋トランザクショングループ
Copy-on-Write	なし	なし	あり	あり
スナップショット	なし（LVM等が必要）	なし（LVM等が必要）	あり（サブボリューム単位）	あり（データセット単位）
チェックサム	なし	なし	メタデータのみ	データ＋メタデータ両方
自己修復	なし	なし	限定的（冗長構成時）	あり（RAID-Z構成時）
動的inode割り当て	なし（フォーマット時固定）	あり	あり	あり
RAID統合	なし（外部mdadm等）	なし（外部mdadm等）	RAID 0/1/5/6	RAID-Z1/Z2/Z3
Linuxカーネル統合	mainline	mainline	mainline	DKMS（OpenZFS外部）
安定性・本番実績	高（広範なデフォルト採用）	高（RHEL標準）	中（機能は揃うが複雑性高）	高（FreeBSD/ZFSオリジン）

ext4は「シンプルで安定、最も広く使われる汎用選択肢」、XFSは「大規模ファイル・大容量ストレージでの高スループット特化」、Btrfsは「スナップショットとロールバックをLinux標準ツールで扱いたい環境」、ZFSは「データ完全性・自己修復・レプリケーションを統合管理する高機能環境」として位置付けられます。この大まかな分類を起点に、以降のセクションで判断の詳細を詰めていきます。

スナップショット機能の有無と使い方の設計境界

スナップショットがある設計とない設計で変わる運用フロー

ext4とXFSはファイルシステム単体にスナップショット機能を持ちません。スナップショットが必要な場合はLVM thin provisioningを上位に置くか、クラウド環境ではEBSスナップショット等の外部機能に委ねる設計になります。LVMスナップショットはCoW方式で取得しますが、スナップショット保持数が増えると元LVへの書き込み速度が低下する特性があります。一般的な運用設計では同時保持数を5〜10本以内に制限し、古いものを定期削除するスクリプトを組み込むことで性能劣化を抑制します。この上限値を設計書に明記しておかないと、無制限に積み重ねた結果として性能問題が顕在化するケースがよくあります。

BtrfsとZFSのスナップショット機能の設計上の違い

BtrfsのサブボリュームスナップショットはOS標準ツールで取得でき、systemd-homeやDockerのbtrfsストレージドライバーと連携しやすいのが特徴です。ただしサブボリューム数が増えると管理が複雑になり、整合性チェックのscrub処理に要する時間も長くなります。ZFSのスナップショットは即時取得でき、差分レプリケーション（zfs send/receive）で別ホストへのデータ転送まで一貫して設計できます。スナップショットを「バックアップ転送の起点」として使う用途ではZFSが設計上有利であり、ローカル世代管理だけが目的ならBtrfsで十分です。用途の中心をどこに置くかで選択肢が絞れます。

スナップショット運用のよくある設計ミス

よくあるつまずきとして、「スナップショットを取れば即バックアップ完了」と判断する誤りがあります。スナップショットは同一ストレージプール内の差分記録であり、ディスク障害や誤ったコマンド実行によるプール破壊に対しては無力です。スナップショットはあくまでロールバックの手段であり、別媒体・別ロケーションへの複製と組み合わせて初めてバックアップ設計が完成します。この区別を設計書や運用手順書に明記しておかないと、チーム内でスナップショットをバックアップと同義に扱う認識ズレが発生しやすく、障害発生時の対応が遅れる原因になります。

大量小ファイルとシーケンシャル大容量で選定が変わる点

大量小ファイル（100万ファイル超）での各方式の挙動

小ファイルが100万を超える環境では、ディレクトリエントリの検索性能とinode枯渇がボトルネックになります。ext4はフォーマット時にinode総数を確定する設計のため、ファイル数が予測より急増するとinodeが枯渇します。フォーマット後の変更にはリフォーマットが必要になるため、マウント後にinode使用率を定期監視する運用設計が不可欠です。一方XFSは動的inode割り当てを採用しているため事前のinode数設定が不要で、大量ファイル環境への適応性が高くなっています。BtrfsとZFSも動的割り当てですが、小ファイルが大量にある環境ではメタデータ領域の管理コストが上がる点を把握しておく必要があります。

大容量シーケンシャルIO（動画・バックアップ・DBダンプ）での選定

100GB超のファイルを連続的に書き込む用途（動画トランスコード、DBフルダンプ、バックアップアーカイブ等）では、XFSのディレクトリ管理とエクステントアロケーションが有効です。一般的な傾向として、大容量HPC環境やメディアサーバーでXFSが採用される理由は、大規模ファイルでのCPUメタデータ処理コストがext4より低く抑えられる点にあります。CoW系のBtrfsやZFSでこのユースケースを扱う場合は、nodatacow等のオプションやデータセット設定で書き込み増幅を抑制することが設計上の前提条件になります。手を動かす設定の詳細は本体の構築手順で確認してください。

混在ワークロードでの設計方針

小ファイルと大ファイルが混在するワークロード（Webアプリのアセット配信サーバー、画像・動画のストレージ等）では、単一ファイルシステムで全要件を満たそうとすると設計が歪みます。一般的な設計手法として、アセット静的ファイル群はXFSマウントポイント、大容量メディアはZFSプールという形でパスを分けて用途別に使い分ける方式があります。システムルート（/）はext4やXFSに任せ、データ専用パーティションでBtrfsやZFSを選ぶパーティション設計の分離も有効な手段です。単一方式に統一することを目的にせず、用途ごとに最適なファイルシステムを割り当てる発想が設計の基本になります。

マウントオプションとジャーナリング設定の設計判断

noatimeとrelatimeの使い分け

atime（アクセス時刻）の更新はファイルを読むたびにメタデータ書き込みが発生するため、読み取り主体のサービス（画像配信、ログ収集）ではnoatimeをマウントオプションに指定するとメタデータIOを削減できます。一方でatimeを参照するプロセス（特定のメールMDAや一部のcronジョブ）ではatimeが更新されないと誤動作する場合があります。relatimeはアクセス時刻をmodify timeより古い場合のみ更新する折衷案で、多くのLinuxカーネルではrelatimeがデフォルトになっているため、明示的に変更する理由がなければそのままにするのが安全な選択です。noatimeを指定する前に、稼働予定のプロセスがatimeに依存していないかをあらかじめ確認してください。

ジャーナリングモードの選定判断（ext4）

ext4のジャーナリングモードにはordered・journal・writebackの三段階があります。orderedはデータをジャーナルに書かずメタデータのみを記録し、データ書き込み後にメタデータをコミットする方式で、安全性とパフォーマンスのバランスが取れたデフォルト設定です。writebackはメタデータのみジャーナルに記録してデータ書き込みの順序保証がないため高速ですが、クラッシュ時にファイルに古いデータが残るリスクがあります。アプリケーション側でfsyncを制御しているデータベースのデータ領域であればwritebackを検討できますが、汎用ストレージにはorderedを維持することを推奨します。

barrier設定と電源断リスクの考慮

書き込みバリアはジャーナルのコミット順序を保証するための設計で、有効時はバッテリーバックアップ付きライトキャッシュがない環境でもデータ整合性を確保できます。クラウドインスタンスのマネージドブロックストレージ（EBSなど）は永続性をプラットフォームが保証しているためnobarrierを指定しても安全という議論がありますが、クラウドプロバイダーの保証内容を個別に確認した上で判断することを推奨します。物理サーバーでHBAライトキャッシュが有効な場合も同様に、キャッシュの電源保護（バッテリー・キャパシタ）の状態によって判断が変わるため、HBAの仕様確認を設計フェーズに含めてください。

クラウドインスタンスと物理サーバーで選定が変わる条件

クラウドブロックストレージとの組み合わせ設計

EBS（AWS）・Persistent Disk（GCP）・Azure Managed DiskのようなクラウドマネージドブロックストレージはハードウェアRAIDやレプリケーションをプラットフォーム側が管理しています。そのためZFSやBtrfsのRAID機能を重ねるメリットは薄く、ZFSのチェックサムや自己修復が不要なケースも多くなります。クラウド環境ではext4またはXFSをシンプルに載せてバックアップをスナップショットAPIに委ねる設計が一般的であり、ZFSのオーバーヘッド（メモリ使用量・初期設定の複雑さ）を払う合理性は限定的です。インスタンスの一時ディスク（instance store）を使う場合はデータ揮発性を前提にした設計が別途必要になります。

物理サーバーでZFS/Btrfsが選ばれる条件

物理サーバーでZFSが採用される代表的な条件は、複数ディスクをZPOOLで管理してRAID-Zを構成する、バックアップ転送にzfs send/receiveを使う、チェックサムによるサイレントデータ破損の検出が必要、の三点が揃う場合です。自己修復機能はRAID-Zと組み合わせて初めて有効に機能するため、単一ディスクでZFSを選んでも修復能力は利用できません。ZFSは最低でも4GB以上のRAMを確保することが推奨されており（ARC用）、メモリが少ない物理サーバーでは性能が出にくい特性があります。Btrfsは小規模物理環境（10台規模の想定例）でスナップショットとロールバックだけを目的に使うケースに向いています。

コンテナ環境での選定注意点

KubernetesノードOSやDockerホストではコンテナランタイムのストレージドライバーとファイルシステムの組み合わせ互換性を確認する必要があります。overlay2ストレージドライバーはext4とXFSで安定稼働が確認されており、本番環境での実績が豊富です。Btrfsドライバーも利用可能ですが、Docker公式ドキュメントではoverlay2が推奨されているため、特別な理由がない限りコンテナ用途ではoverlay2＋XFSまたはext4の組み合わせが安全な選択肢です。ノード数が50台を超える規模になると、ストレージドライバーの安定性が運用コストに直結するため、実績のある組み合わせを優先することが重要です。

ファイルシステム変更時のデータ移行手順設計

インプレース変換の可否と限界

ファイルシステムの変更は基本的にインプレース（既存データを残したまま）では行えません。ext2→ext3→ext4は段階的なアップグレードが可能ですが、ext4→XFSやext4→ZFSへの変更は新規フォーマットと完全なデータ移行が必要です。「パーティションのフォーマットを変えるだけ」という誤解は移行計画を立てる際によくあるつまずきで、移行作業には既存ストレージ容量の1.5〜2倍の作業領域を確保した上で計画を立てる必要があります。本番環境での変更は影響範囲が広いため、事前にステージング環境での検証を十分に行った上で移行設計を確定してください。

移行設計のチェックリスト

ファイルシステム変更の移行設計では、以下の項目を順に確認してください。

1. 移行先ファイルシステムのフォーマットオプション・マウントオプションの設計と確認
2. 既存データの完全バックアップ（別媒体・別ロケーション）と整合性チェック
3. 移行先への初期データ転送とチェックサム照合による転送検証
4. アプリケーション側の接続先パスとfstabの切り替え設計
5. 切り替え後の動作確認とIOパフォーマンス検証（設計値との比較記録）
6. 旧ストレージの即時廃棄ではなく一定期間（最低2週間）の保持と段階的廃棄

特に手順3のチェックサム照合を省略すると、転送中のビット化けを見逃すリスクがあります。大規模データ（10TBを超える想定例）では転送完了後の照合に数時間単位の工数がかかることを見積もりに含めてください。チェックリストは設計書に添付し、担当者が変わっても同じ手順を踏めるよう整備しておくことが重要です。

本番環境での移行リスク低減設計

本番環境でのファイルシステム移行は、サービスを止めないホットマイグレーションが求められるケースがほとんどです。LVMのスナップショットと並行マウントを組み合わせた段階的移行や、クラウドであれば新ボリュームを用意して並行稼働後に切り替える方式が一般的に採られます。移行後の性能検証フェーズでは、fio等のベンチマークツールで実ワークロードに近い条件でIOPSとレイテンシを計測し、設計値との乖離を記録しておくことが次回の選定判断材料になります。ファイルシステムの選定は一度決めると変更コストが高い判断であるため、構築フェーズでワークロード特性をあらかじめ洗い出し、選定根拠を設計書に明記しておくことが長期的な運用品質の土台になります。