Linux / ext4・XFS・Btrfsの比較：違いと選び方

ext4・XFS・Btrfsを選ぶときは、新しさよりもディストリビューションのサポート、必要な機能、サイズ変更と復旧の方法を比較することが大切です。使い慣れた管理方法とオフラインでの縮小を重視するならext4、大容量ストレージと並列入出力を扱うサーバーならXFS、ファイルシステム標準のスナップショット・圧縮・データチェックサムが必要ならBtrfsが検討対象になります。ただし、これは選択の出発点であり、実際の性能と運用への適合性は使用環境で確認する必要があります。

この記事では、Linux PCと一般的なサーバーのローカルディスクで使用する3種類のファイルシステムを比較します。ファイルシステムとは、ファイルの内容と名前・保存場所・権限などの情報を保存し、取り出すための仕組みです。ディスク・パーティション・マウントの関係が曖昧な場合は、ディスク・パーティション・ファイルシステムの違いを先に確認すると、比較の基準を理解しやすくなります。

ext4・XFS・Btrfsの違いを一覧で比較

メタデータは、ファイルの保存場所・サイズ・権限などの管理情報です。ジャーナリングは変更の記録を使い、異常終了後にファイルシステムの整合性を回復しやすくする仕組みであり、バックアップやすべてのファイル内容の保存を保証するものではありません。Copy-on-Write（CoW、変更時コピー）は、変更内容を新しい領域に書き込み、その参照先を更新する方式です。

表の「なし」は、ファイルシステム自体の機能についての記載です。ext4・XFSでも、論理ボリュームマネージャー（Logical Volume Manager、LVM）、ストレージ装置、仮想化基盤のスナップショットを利用できます。XFSのreflinkのようにデータブロックを共有するファイルコピーも、ファイルシステム全体のある時点を保持するスナップショットとは異なります。チェックサムの行は通常のファイル内容を対象としており、ext4・XFSにメタデータ保護がないという意味ではありません。

ext4：使い慣れた管理方法とオフライン縮小を重視する場合

ext4はFourth Extended Filesystemの略で、ext2・ext3の系統を引き継ぐファイルシステムです。Debian 13のインストールガイドでは、多くの場合にext4が既定で選択されると説明されています。特別な機能要件がないシステムでは、ディストリビューションのインストール・復旧ツールと合わせて検討しやすい候補です。ただし、既定であることだけで、ほかのファイルシステムより常に高速・安全だと判断することはできません。ディストリビューションの選択肢はDebian 13の公式インストールガイドで確認できます。

ext4の標準的なdata=orderedモードは、メタデータをジャーナルに記録し、関連するデータの書き込み順序を管理します。すべてのファイル内容をジャーナルへ二重に保存する方式ではありません。そのため、停電後にファイルシステムをマウントできることと、アプリケーションの最後の書き込みが保存されていることは区別する必要があります。動作の詳細はLinuxカーネルのext4管理ドキュメントに説明されています。

運用上の違いとして重要なのが縮小です。resize2fsは、条件を満たすext4をマウント中に拡張できますが、縮小にはアンマウントが必要です。ルートファイルシステムの縮小では、通常、別の起動環境と停止時間を用意します。このツール自体はパーティションのサイズを変更しないため、ファイルシステムとその下位の領域を別々に管理する必要があります。実際の環境に適用できる条件をresize2fsのマニュアルで確認してください。

例えば、後からOS用領域とデータ用領域の容量を再配分する予定があるなら、縮小の可否と停止時間を事前に比較する必要があります。一方、状態を戻すためのスナップショットが主な要件なら、ext4を選ぶだけでは実現できず、LVMなどのバックアップ・スナップショット層も設計する必要があります。

XFS：大容量ストレージと並列入出力を扱うサーバーで

XFSは領域を割り当てグループに分けて管理し、大きなファイルや複数処理の並列入出力を考慮する場合に検討しやすいファイルシステムです。Red Hat Enterprise Linux（RHEL）10は、既定のローカルファイルシステムにXFSを採用しています。組織のディストリビューション、ストレージ管理ツール、復旧手順がXFSを中心に整備されているなら、その運用支援も重要な選択理由になります。対応範囲と条件はRHEL 10のファイルシステム比較・管理ドキュメントで確認できます。

XFSの拡張にはxfs_growfsを使用し、マウントした状態で実行します。先に下位のデバイスから追加容量が提供されている必要があり、ディスクや論理ボリュームを拡張しただけでファイルシステムも自動的に同じ大きさになるとは限りません。拡張計画では、ディスク・パーティション・論理ボリューム・ファイルシステムのどの層を変更するのかを区別します。

縮小を「絶対に不可能」とも「一般的に利用可能」とも断定しないことが大切です。RHEL 10.0のリリースノートでは、最後の割り当てグループ内で、削除する範囲にデータとメタデータが割り当てられていない場合の限定的な縮小を、技術プレビュー（Technology Preview）として案内しています。任意のサイズへ縮小する一般的な運用手順とは異なります。縮小が重要な要件なら、この限定機能を前提に選ばず、ディストリビューションの正式サポートを確認するか、より小さい新しいファイルシステムへのバックアップ・復元を計画してください。条件はRHEL 10.0の限定的なXFS縮小に関する説明とxfs_growfsのマニュアルに記載されています。

ファイル共有サーバーや大きなデータファイルを扱うサーバーでは、XFSを候補に含めつつ、ファイルサイズだけで決めないようにしましょう。小さなファイルの作成・削除頻度、同時アクセス数、同期書き込みと遅延時間の要件まで、実際のサービスに近い条件で確認する必要があります。

Btrfs：スナップショット・圧縮・チェックサムを活用する場合

BtrfsはCoWを基盤とし、サブボリューム、スナップショット、透過圧縮、データとメタデータのチェックサムを提供します。チェックサムとは、保存内容から計算する検証値で、読み戻した内容に変化がないかを判断するために使います。FedoraのデスクトップエディションとスピンはBtrfsを既定にしていますが、すべてのサーバーやディスク構成がサポートされるという意味ではありません。Btrfs公式の機能紹介とFedoraのBtrfs案内を参照してください。

サブボリュームは、ファイルシステム内で独立して管理できるディレクトリツリーです。スナップショットは最初に元のデータブロックを共有し、その後の変更に応じて追加容量を使用します。更新前の状態を保持する用途に使えますが、Btrfsを選ぶだけで自動スナップショット、保存期間、起動時の復旧メニューがすべて設定されるわけではありません。ディストリビューションのツールとサブボリューム構成を合わせて確認する必要があります。

同じディスク上のスナップショットは、別のバックアップの代わりにはなりません。元のデータとスナップショットは同じ装置と共有ブロックに依存するため、装置の故障や共有ブロックの破損で両方を失う可能性があります。また、入れ子のサブボリュームは親のスナップショットに再帰的には含まれません。書き込み中のデータベースなどでは、アプリケーション自身のバックアップや書き込みの一時停止など、整合性を確保する手順も必要です。範囲と制約はBtrfsのサブボリューム・スナップショット文書に説明されています。

エラーの検出と修復も区別してください。btrfs scrubはチェックサムなどを検査しますが、破損した内容の修復には、対象ブロックの正常な冗長コピーが必要です。単一ディスクにデータを1部だけ保存する構成では、破損を検出できても元の内容を復元するコピーがない場合があります。NOCOWを設定したファイルでは、データのチェックサムが適用されない例外もあります。検査と修復の条件はBtrfs scrubの公式文書で確認できます。

圧縮は、データの特性によって使用容量と入出力を減らせますが、圧縮済みの動画やアーカイブでは効果が小さい場合があります。上書きが多い仮想マシンのイメージやデータベースでは、CoW、断片化、スナップショットの保持方針を合わせて検討してください。性能だけを理由にNOCOWを一律適用すると、データのチェックサムと圧縮にも影響します。関連条件はBtrfsのマウントオプション文書に記載されています。

複数ディスクを組み合わせる場合は、RAID（Redundant Array of Independent Disks、複数の独立したディスクを組み合わせる方式）のプロファイルごとに状態を確認する必要があります。公式の機能紹介では、RAID5/6は実験的で本番環境には適さないと説明されています。ほかのプロファイルと同等に扱わず、カーネル・ツールのバージョンとBtrfsの機能別対応状況を確認してください。

利用環境に応じたファイルシステムの選び方

以下は、機能の違いを実際の要件に結び付けた判断基準です。優劣の順位や、すべての環境に共通する推奨設定ではありません。

例えば、更新失敗後にOSを戻すことが主目的なら、Btrfsの機能に加え、復旧ツールがどのサブボリュームを戻すのかを確認します。OSだけを復元してユーザーデータは維持するのか、両方を同じ時点に戻すのかで設計が変わります。一方、データ領域を拡張し続けるサーバーでは、縮小よりもディストリビューションのサポートと拡張・バックアップ手順が重要になる場合があります。

性能比較でそろえるべき条件

ファイルシステム名だけで速度を予測することは困難です。同じSSDでも、小さなファイルを大量に作る処理、大きなファイルの順次読み込み、データベースの同期書き込みでは結果が異なります。短時間のコピー試験は、メモリキャッシュの影響を強く受ける場合もあります。

• 保存装置：同じSSD・HDDと接続方式、使用量・空き容量の条件を使います。
• 処理の特性：ファイルのサイズ・数、読み書きの比率、順次・ランダムアクセス、同時実行数をそろえます。
• 機能と設定：圧縮、CoW、スナップショット、暗号化、マウントオプションを記録します。機能の有効・無効が異なる結果を同条件として比較しません。
• データ保持条件：アプリケーションの同期書き込みと装置のキャッシュ方針をそろえます。データ保持の保証を弱める設定を、単純な性能向上として評価しません。
• バージョンと指標：カーネル・管理ツールのバージョンを記録し、処理量だけでなく遅延時間と反復試験のばらつきも確認します。

ログ保存サーバーを比較するなら、大きなファイル1個のコピー速度だけでなく、実際の追記・ローテーション・圧縮・バックアップが重なる条件を試験します。圧縮による使用容量の削減とCPU負荷の増加も合わせて判断してください。差が小さい場合は、既存のファイルシステムを変更する移行コストとリスクも考慮する必要があります。

現在の形式の確認と変更前の点検

現在のシステムを変更せずに確認する

一般的なLinux環境では、次のコマンドでデバイス・マウント・容量の情報を参照できます。lsblkとfindmntはutil-linux、GNU/Linuxのdfは通常coreutilsに含まれます。これらのコマンドは、ファイルシステムの新規作成や形式変更を行いません。

lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS
findmnt -T / -o TARGET,SOURCE,FSTYPE,OPTIONS
df -hT /

lsblkではデバイスの階層とFSTYPEを、findmntではルートパスを含むファイルシステムの形式と実際のマウントオプションを確認します。df -hT /はルートパスが属するファイルシステムの形式と容量を表示します。/を実際のデータディレクトリに置き換えると、そのパスを確認できます。

例えば、findmntのFSTYPEがxfsなら、そのパスはXFS上にあります。ディスク自体の行でFSTYPEが空欄でも、パーティションや論理ボリュームの行には形式が表示される場合があります。コンテナではoverlayなどと表示されることがあるため、ホストディスクの形式だと断定しないでください。古いlsblkがMOUNTPOINTSに対応していなければ、MOUNTPOINTに変更します。オプションの詳細はlsblkのマニュアルとfindmntのマニュアルで確認できます。

Btrfsの空き容量が想定と異なる場合は、btrfs filesystem usageでデータ・メタデータとデバイスへの割り当てを確認できます。スナップショットがデータを参照し続けていると、ファイルを削除しても、その分の領域が直ちに解放されない場合があります。ディレクトリ容量の合計だけで判断せず、Btrfsの容量確認・サイズ変更文書の説明を適用してください。

別のファイルシステムへ移行する順序

既存のファイルシステムに別形式のmkfsを実行することは、データを保持したまま変換する方法ではありません。一般的な移行計画は、新しい移行先と復元の検証を中心に組み立てると理解しやすくなります。

1. 元のデバイス・形式・マウント先とアプリケーションのサポート条件を確認し、独立した保存装置にバックアップして、復元できることを検証します。
2. 新しいディスクか別途確保した領域に移行先のファイルシステムを用意します。フォーマット前に、意図した空の対象であることを再確認します。
3. サービス停止やアプリケーション自身のバックアップ機能でデータの整合性を確保し、所有者・権限・アクセス制御リスト（ACL）・拡張属性・ハードリンクなど、必要な情報を保持してコピーまたは復元します。ファイル内容をコピーするだけのツールが、これらをすべて保持するとは限りません。
4. 新しいパスでファイルとアプリケーションを検証し、新しいUUID（ファイルシステム識別子）に合わせて/etc/fstabと関連サービスの設定を変更します。OSのルート領域を移行する場合は、ブートローダーと初期起動環境を含む別の手順が必要です。
5. 再起動後にマウント・サービス・権限を確認します。問題があれば新しい移行先への書き込みを止め、検証済みの元の環境と設定に戻せるよう、切り替えの確認が終わるまで元データとバックアップを保持します。切り替え後に作られたデータも切り戻し計画に含めます。

同じファイルシステムのサイズだけを変える場合も、階層の順序が重要です。拡張は通常、下位の保存領域を先に増やしてからファイルシステムを拡張し、縮小がサポートされる場合はファイルシステムを先に縮小してから下位領域を減らします。Btrfsでも、サイズ変更がパーティションテーブルを自動更新するわけではありません。この原則だけで具体的な実行手順を代替することはできないため、暗号化・LVM・RAIDがある場合は各層の対応手順を確認してください。

エラーがある場合は、ファイルシステムに適したツールを使用する必要があります。ext4のe2fsck、XFSのxfs_repair、Btrfsの検査・復旧ツールは互換ではありません。特にbtrfs check --repairを一般的な最初の解決策として実行しないでください。公式文書は、開発者や経験豊富な利用者の助言なしで使用しないよう案内しています。fsckとファイルシステム別の検査時の注意点、Btrfs検査ツールの警告を確認し、変更前にバックアップと復旧計画を用意してください。