選ぶ前に決めておく3つの条件
ファイルシステムを選ぶ前に、次の3点を決めておきます。1つ目は、スナップショットを使うかどうかです。スナップショットとは、ある時点のファイルの状態を瞬時に保存する機能です。更新に失敗したときに元へ戻せます。2つ目は、あとでパーティションを縮小する可能性があるかどうかです。3つ目は、障害が起きたときに自分で調べて直せる情報量がどれだけあるかです。
スナップショットが要らず、なるべく手間をかけたくないなら ext4 か XFS が候補です。スナップショットやデータの破損検出がほしいなら Btrfs か ZFS が候補です。ext4 と XFS は仕組みが単純で、扱える人も多くいます。Btrfs と ZFS は機能が多いぶん、覚えることも増えます。
4つのファイルシステムの比較表
| 観点 | ext4 | Btrfs | XFS | ZFS |
|---|---|---|---|---|
| 安定性 | 非常に高い | 単体ディスクとRAID1は実用的。RAID5/6は非推奨 | 非常に高い | 高い。ただしカーネル外のモジュール |
| スナップショット | なし(LVMで代替) | あり | なし(LVMで代替) | あり |
| 性能の傾向 | 全般に安定 | CoWのため書き換えの多い大きなファイルが苦手 | 大きなファイルと並列I/Oに強い | キャッシュ用にメモリを多く使う |
| 拡張 | オンラインで可 | オンラインで可 | オンラインで可 | ディスクの追加で可 |
| 縮小 | アンマウントすれば可 | オンラインで可 | 実質的に不可 | 原則不可(条件付きで一部可) |
| 修復 | e2fsck が成熟 | scrub が中心。修復コマンドは慎重に使う | xfs_repair が成熟 | zpool scrub と冗長構成による自己修復 |
CoW(コピーオンライト)は、データを上書きせずに別の場所へ書いてから参照先を切り替える方式です。スナップショットを安く作れる反面、断片化が起きやすくなります。
ext4：情報が多く壊れにくい標準、スナップショットはない
ext4 は多くのディストリビューションで長く既定に採用されてきました。障害時の情報が最も多いことが強みです。e2fsck による修復も枯れています。容量はオンラインで拡張できます。縮小はアンマウントした状態で resize2fs を使えば可能です。
弱点は、スナップショット機能を持たないことです。データのチェックサムもないため、ディスクが静かにデータを壊しても検出できません。スナップショットが必要なら、LVM(論理ボリュームマネージャ)を下に敷くか、rsync ベースのバックアップツールで補います。
Btrfs：スナップショットは手軽だが、RAID5/6は避ける
Btrfs はサブボリューム、スナップショット、透過圧縮、データのチェックサムを標準で備えます。Fedora の Workstation 版や openSUSE では既定のファイルシステムです(執筆時点)。拡張も縮小もマウントしたまま行えます。
弱点は3つあります。まず RAID5/6 は、電源断時にデータの整合性が崩れる「書き込みホール」の問題があり、公式ドキュメントで本番利用は推奨されていません。複数ディスクで使うなら RAID1 か RAID10 にします。次に、仮想ディスクイメージやデータベースのように一部を頻繁に書き換えるファイルでは、CoW による断片化で性能が落ちます。対象ディレクトリに chattr +C で CoW を無効化できますが、そのファイルはチェックサムの対象外になります。最後に、btrfs check --repair は状況によって被害を広げることがあり、公式にも最終手段とされています。障害時はまず btrfs scrub や読み取り専用マウントでデータを退避するのが基本です。
XFS：大容量と並列書き込みに強いが、縮小できない
XFS は大きなファイルと多数の同時書き込みで性能を出しやすい設計です。RHEL 系ディストリビューションの既定です。xfs_growfs でオンライン拡張でき、xfs_repair による修復も成熟しています。
最大の弱点は、ファイルシステムを縮小できないことです。縮小したいときは、バックアップを取って作り直すしかありません。最初に大きく割り当てすぎると後から取り返せないため、LVM と組み合わせて必要な分だけ割り当て、少しずつ広げる運用が向いています。スナップショット機能もないので、ext4 と同じく LVM などで補います。
ZFS：機能は最も豊富だが、カーネルの外にある
ZFS はディスクの束ね方(RAID-Z やミラー)、ボリューム管理、スナップショット、圧縮、チェックサムを一体で提供します。冗長構成なら、読み出し時に壊れたデータを検出して正しいコピーから自動で直します。zfs send と zfs receive で、スナップショットを別のマシンへ差分転送することもできます。
弱点はライセンスです。OpenZFS は CDDL というライセンスで配布されています。CDDL は Linux カーネルの GPL と両立しないとされるため、カーネル本体には含まれません。ディストリビューションが別途用意するモジュールか、DKMS(カーネル更新時にモジュールを自動で再ビルドする仕組み)で入れます。新しいカーネルへの対応が遅れることがあり、更新直後にプールが読めなくなる場合があります。最新カーネルを追うディストリビューションでは特に注意が必要です。Ubuntu はモジュールを公式に同梱していますが、多くのディストリビューションは自前での導入です。
容量面では、ディスクを追加しての拡張はできますが、プールの縮小は原則できません。ミラー構成などでは条件付きでデバイスを取り外せますが、RAID-Z 構成では取り外せません。また ARC と呼ばれる読み込みキャッシュがメモリを多く使います。メモリの少ないマシンには向きません。
用途別の選び方
デスクトップ
ディストリビューションの既定をそのまま使うのが最も安全です。システム更新の失敗から戻したいなら Btrfs が向いています。Snapper や Timeshift と組み合わせれば、更新前のスナップショットへ戻せます。ただし Timeshift の Btrfs モードは、Ubuntu 型のサブボリューム構成(@ と @home)を前提にしています。手間を減らしたい人や、トラブル時に検索で答えを見つけたい人には ext4 が向きます。
ノートPC
ディスクが1台で容量も限られるため、Btrfs の透過圧縮とスナップショットが効きます。持ち歩く機械は落下や電池切れが起きやすいので、スナップショットとは別にバックアップも取ります。ZFS はメモリ消費とモジュール管理の手間から、ノートPCでの優先度は低めです。
NAS・ホームサーバー
データ保全を最優先するなら ZFS が有力です。冗長構成と定期的な scrub で、静かなデータ破損に対処できます。TrueNAS のような ZFS 前提の専用OSを使えば、モジュールの事情もほぼ気にせずに済みます。後からディスクを1台ずつ足したい、容量の違うディスクを混ぜたいなら、Btrfs の RAID1 が柔軟です。RAID5/6 相当の容量効率がほしい場合、Btrfs ではなく ZFS の RAID-Z か、mdadm と ext4/XFS の組み合わせを選びます。
仮想マシン
ゲスト側は ext4 か XFS が無難です。スナップショットはハイパーバイザー側で取れるので、ゲストに Btrfs を使う理由は小さくなります。仮想ディスクは後から縮小したくなることがあるため、その可能性があるなら XFS より ext4 にします。ホスト側でイメージを置く場合、Btrfs ならイメージ用ディレクトリの CoW を無効化します。ZFS ならイメージ置き場として zvol(ブロックデバイスとして切り出した領域)を使えます。
決める前に試すこと
迷ったら、条件を順に確認します。スナップショットが要らなければ ext4 にします。大容量で縮小の予定がなければ XFS も選べます。スナップショットが要り、ディスクが1〜2台なら Btrfs を選びます。複数ディスクのデータ保全が目的で、モジュール管理を許容できるなら ZFS を選びます。
本番に入れる前に、仮想マシンで試しておきます。スナップショットからの復元、容量の拡張、ディスクを1台外したときの挙動を一度ずつ実行してください。手順を自分で再現できたファイルシステムが、障害時に頼れる選択です。どれを選んでも、スナップショットはバックアップの代わりになりません。別のディスクや別のマシンへのバックアップも用意します。