ファイルシステムを選ぶ際に多くのsysadminが直面する問題
sysadminを始めたばかりの頃、ログをちゃんと読まなかったせいで午後をまるまるデバッグに費やしたことがある。MySQLを動かしていたdatabase serverが新しいサーバーへの移行後、深刻なパフォーマンス低下を起こしたのだ。結局シンプルな原因が判明した。新しいサーバーはデフォルトのmount optionsでext4を使っていたのに対し、古いサーバーはrandom I/Oが多いworkload向けに丁寧にチューニングされたXFSを使っていたのだ。
distroをインストールする際のデフォルトファイルシステムはたいていext4だ。database serverであれ、file serverであれ、streamingであれ、誰もそれに疑問を持たない。しかし「ext4かXFSか？」という問いはシンプルに見えて、実際に動かしているworkloadによって答えは全く変わってくる。
ファイルシステムがあなたの思う以上に重要な理由
ファイルシステムは単にファイルを保存する場所ではない。kernelがmetadataをどう管理するか、journalをどう処理するか、blockの割り当てメカニズム、cacheの戦略を決定する。1秒間に数千のtransactionを処理するdatabase serverでは、ファイルシステムの違いが実測パフォーマンスで20〜40%もの差につながることがある。
選択する前に考慮すべき4つの要素がある：
- Workloadのパターン：Sequential read/write（streaming、backup）かrandom I/O（database、VM disk）か？
- ファイルサイズ：小さいファイルが多い（mail server、web server）か、大きいファイルが少ない（video storage、backup）か？
- 機能要件：snapshot、compression、または統合RAIDが必要か？
- ストレージの種類：従来のHDD、SSD、それともflash storage？
各ファイルシステムの詳細分析
ext4 — 信頼できる定番の選択
どのサーバーにUbuntuをインストールしても？ext4だ。CentOS？ext4。Debian？やっぱりext4。これは偶然ではない。このファイルシステムは安定していて、15年以上にわたって十分に検証されており、Linuxエコシステムの中で最も充実したツールセットを持っている。
メリット：
- 優れたjournaling機能、クラッシュ後の高速かつ信頼性の高いリカバリ
- 成熟したツール群：
fsck、debugfs、tune2fs— ドキュメントも充実、StackOverflowの解決策も豊富 - HDDとSSDの両方で安定して動作する
- オーバーヘッドが低く、RAM容量が限られたサーバー（4GB以下でも）に適している
デメリット：
- ネイティブのsnapshotが無い — snapshotが必要な場合はLVMや別のストレージレイヤーを使う必要がある
- 数十万個の小さなファイルを含むディレクトリではパフォーマンスが低下する
- compressionやdeduplicationが統合されていない
SSD向けの最適なoptionsでext4をフォーマットしてマウントする：
# lazy initializationをオフにしてフォーマット（SSDに最適）
mkfs.ext4 -E lazy_itable_init=0,lazy_journal_init=0 /dev/sdb1
# 最適なoptionsでマウント — noatimeでwriteを削減、discardでTRIMを有効化
mount -o noatime,discard /dev/sdb1 /data
# /etc/fstabに追加
/dev/sdb1 /data ext4 defaults,noatime,discard 0 2
# journal commitインターバルのチューニング（デフォルト5s、延ばすことでI/Oを削減）
tune2fs -o journal_data_writeback /dev/sdb1XFS — databaseと高負荷workloadの定番選択
XFSはRHEL 7からRed Hatのデフォルトファイルシステムとして採用されている。これも偶然ではない。最初から大きなファイルと複数プロセスからの並列I/Oの高パフォーマンスを念頭に設計されており、実際のdatabaseベンチマークでXFSが圧倒的な結果を出す理由がここにある。
本当に際立つメリット：
- 大きなファイルとsequential I/Oに対する優れたパフォーマンス
- 独立したmetadata journaling、data throughputに影響しない
- Online resize — マウント中にサイズを拡張できるため、ダウンタイム不要
- Delay allocationがfragmentationを大幅に軽減する
- 複数processからの同時writeがext4より明らかに優れており、特に8スレッド以上の同時実行で威力を発揮する
デメリット：
- ファイルシステムのshrinkができない — 拡張のみ可能で縮小はできない。formatする前に容量をしっかり計算すること
- ネイティブのcompressionやdeduplicationが無い
# enterprise SSDに適したsector sizeでXFSをフォーマット
mkfs.xfs -f -s size=4096 /dev/sdb1
# database server向けのoptionsでマウント
mount -o noatime,logbsize=256k,largeio /dev/sdb1 /data
# XFSの確認と修復（先にアンマウントすること）
xfs_repair /dev/sdb1
# XFSをオンラインで拡張（ファイルシステムがマウントされている状態で）
xfs_growfs /data
# ファイルシステムの詳細情報を表示
xfs_info /dataBtrfs — 機能豊富だが、万人向けではない
Fedora 33はBtrfsをデフォルトに切り替えた。当時かなり大胆な決断だった。openSUSEはさらに早くからBtrfsを採用していた。両者ともそのsnapshot機能とself-healing能力に賭けたわけだが、振り返ってみれば間違いではなかった。
本当に際立つ機能：
- ネイティブSnapshot：copy-on-writeにより、即座にsnapshotを作成でき、作成直後は追加スペースの消費がない
- インラインCompression：LZO/zlib/zstdの透過的な圧縮 — テキスト/ログデータで実際に20〜40%のスペース節約
- Subvolume：従来のpartitionより柔軟な管理が可能で、事前に容量を割り当てる必要がない
- データ+メタデータのChecksum：bit rotを自動検出 — ext4やXFSにはできない機能
productionで使用する前に注意すべき点：
- BtrfsのRAID 5/6には既知のバグがある — productionでは使用しないこと、代わりにmdadmかZFSを使うこと
- 純粋なrandom writeのパフォーマンスはベンチマークでext4/XFSより約10〜15%劣る
btrfsckはe2fsckほど成熟しておらず、深刻なcorruptionが発生した場合のrecoveryが複雑になる
# Btrfsをフォーマット
mkfs.btrfs -L "data-volume" /dev/sdb1
# zstd compressionでマウント（圧縮率が良く、zlibより高速）
mount -o compress=zstd:3,noatime /dev/sdb1 /data
# subvolumeを作成（論理partitionのようなものだが、より柔軟）
btrfs subvolume create /data/www
btrfs subvolume create /data/db
# 読み取り専用Snapshot（即座に作成、初期は追加スペース不要）
btrfs subvolume snapshot -r /data/www /data/snapshots/www-$(date +%Y%m%d)
# すべてのsubvolumeとsnapshotを一覧表示
btrfs subvolume list /data
# compressionの圧縮率込みでusageを確認
btrfs filesystem df /data
btrfs filesystem usage /dataF2FS — flash storage専用の選択
enterprise serverでF2FSに出会ったことがなくても、それは普通のことだ。SamsungがこのファイルシステムをNAND flashの具体的な問題、つまり高いwrite amplificationと不均一なwear patternを解決するために開発した。F2FSはwrite patternを最適化することでデバイスの寿命を延ばす。
メリット：
- NAND flashのwrite amplificationを削減し、SSD/eMMCの寿命を大幅に延ばす
- consumer-grade SSD上でext4よりrandom I/Oのパフォーマンスが優れている（ベンチマークで通常10〜20%）
- hot/coldデータを自動的に分離し、時間経過によるfragmentationを軽減する
制限事項：
- flash storageにのみ適している — HDD上ではext4よりパフォーマンスが劣る
- ext4/XFSと比べてツールのサポートやドキュメントが明らかに少ない
- enterprise server環境では普及していない
# F2FSツールをインストール（Ubuntu/Debian）
apt install f2fs-tools
# F2FSをフォーマット
mkfs.f2fs /dev/sdb1
# マウント
mount -t f2fs /dev/sdb1 /data
# 情報を確認
dump.f2fs /dev/sdb1実際のマッピング：シナリオ別のファイルシステム選択
実際の運用経験から、workload別のマッピングを紹介する：
| シナリオ | 推奨ファイルシステム | 主な理由 |
|---|---|---|
| General purpose Linux server | ext4 | 安定性、リスクが少ない、ツールサポートが最も充実 |
| Database server (MySQL/PostgreSQL) | XFS | 高いconcurrent I/O、独立したmetadata journal |
| NAS / Snapshotが必要なStorage server | Btrfs | Snapshot + compressionでスペースを大幅に節約 |
| Desktop Linux (Fedora/openSUSE) | Btrfs | アップデート前のSnapshot、簡単なrollback |
| Consumer SSD / flash機器 | F2FS | flashの寿命を最適化、random I/Oが優秀 |
| High-throughputログ / Streamingサーバー | XFS | 高速sequential write、優れたdelay allocation |
workloadに応じてファイルシステムを使い分ける — すべてに1つを押しつけない
productionサーバーが均一なworkloadだけを実行することはまれだ。database + backupサーバーなら2つの異なるファイルシステムが必要で、利便性のために1つに押しつける必要はない。私は以下のように分けている：
# 現在のlayoutを確認
lsblk -f
# database + backup serverの最適なlayoutの例：
# /dev/sda1 ext4 / — Root：安定性高く、recoveryが容易
# /dev/sdb1 xfs /var/lib/mysql — Database：concurrent I/Oが高い
# /dev/sdc1 btrfs /backup — Backup：compression + snapshot
# 使用中のすべてのファイルシステムのmount optionsを確認
findmnt -t ext4,xfs,btrfs -o TARGET,SOURCE,OPTIONS
# 決定前にベンチマークして比較する
# （fioをインストール：apt install fio）
fio --name=randwrite --ioengine=libaio --rw=randwrite \
--bs=4k --numjobs=4 --size=1G --runtime=30 \
--filename=/data/testfile --direct=1最も高い代償を払って学んだ教訓：十分にテストせずにproductionサーバーのファイルシステムをmigrateしてはいけない。MySQLのdata partitionをext4からXFSに切り替えた際、事前にデータの全dumpとverifyを怠ったせいで4時間近くのダウンタイムが発生した。stagingでテストし、実際のworkloadでベンチマークしてから、初めてproductionに手をつけよう。
個人的な経験則：/（root）にはext4、databaseや高負荷ログが動くdata diskにはXFS、snapshotとcompressionが必要なstorage serverにはBtrfs。F2FSは純粋なflash storage — 古いノートPC、Raspberry Pi、組み込みデバイス — で作業するときだけ視野に入れる。
