Linuxファイルシステム完全ガイド|ext4・XFSの違いと選び方、作成・確認・運用コマンドまで

  • URLをコピーしました!

Linuxのファイルシステムは、ディスク上のデータ(ファイル)を「どこに」「どういうルールで」保存し、素早く取り出せるように管理する仕組みです。
サーバ運用では、ファイルシステムの理解がそのまま性能・安定性・障害対応力に直結します。

📚 Linux学習の全体像を知りたい方へ
本記事はLinux学習の一部内容です。初心者から現場レベルまでの学習順をまとめたロードマップはこちら。
Linux学習ロードマップ完全版

目次

目次

ファイルシステムとは

ファイルシステムを一言でいうと、「ディスク上のデータに住所と目次を付ける仕組み」です。
ファイル名や更新日時、権限などのメタデータを管理しながら、実データ(内容)を効率的に配置します。

Linuxでは、同じデータでもファイルシステム(ext4 / XFS など)により、性能特性・障害耐性・運用のしやすさが変わります。

ディレクトリ構造(/配下の役割)もあわせて押さえると理解が一気に進みます。

ファイルシステムの内部構造(superblock / inode / data block)

ファイルシステムの内部は、ざっくり以下で構成されます。

  • Superblock(スーパーブロック):ファイルシステム全体の設定・状態(サイズ、ブロック数、inode数など)
  • inode(アイノード):各ファイル/ディレクトリのメタデータ(権限、所有者、サイズ、データの場所など)
  • Data block(データブロック):実際の中身(ファイル内容)

重要:ファイル名はinodeの中ではなく、ディレクトリ(ディレクトリエントリ)が「ファイル名 ↔ inode番号」の対応を持つイメージです。
この構造が、ハードリンク(同じinodeに別名を付ける)の理解にもつながります。

ジャーナリングとは(なぜ障害に強い?)

ジャーナリングは、クラッシュや強制再起動の際にファイルシステム整合性が壊れにくいよう、更新操作の記録(ジャーナル)を持つ仕組みです。
その結果、復旧が速く、運用上の安心感が高いのが特徴です。

ext4とXFSの違い(比較表)

Linuxの代表格として、まずは ext4 と XFS の違いを押さえるのが近道です。

観点ext4XFS
得意領域汎用・安定・小〜中規模で扱いやすい大容量・大規模・高スループット(特に大きいファイル/大量I/O)
運用の癖一般的で情報量が多い修復は基本 xfs_repair(fsck系と思想が少し違う)
ジャーナリングあり(主にメタデータ整合性)あり(メタデータジャーナリング)
採用例(傾向)Ubuntu系で採用されがちRHEL系でデフォルトとして採用されがち

結論として、迷ったら ext4大容量・高負荷・大規模運用なら XFSが基本線になります。

用途別の選び方

① 迷ったら ext4(汎用・安定)

  • 標準的なVM/サーバ(Web/アプリ/小〜中規模DB)
  • 運用情報が豊富で、チーム標準化しやすい

② 大容量・高スループットなら XFS

  • ログ/メディア/バックアップなど大きいファイルが多い
  • ストレージ容量が大きい、I/Oが多い
  • RHEL系標準に寄せたい

③ スナップショット/圧縮/高度機能を重視するなら(補足)

要件によっては Btrfs/ZFS なども候補になりますが、この記事ではまず「現場で最頻出の ext4/XFS」を強くします。
(必要なら、あなたのサイト方針に合わせて別記事/追記で拡張可能です)

確認コマンド(df/lsblk/blkid/mount)

ファイルシステム種別を確認(df -T)

df -T

ブロックデバイスとファイルシステムを確認(lsblk -f)

lsblk -f

UUIDやTYPEを確認(blkid)

blkid

現在のマウント状況を確認(mount)

mount | grep -E "ext4|xfs"

容量まわりの調査は以下も参照してください。

作成・フォーマット(mkfs)とマウント(/etc/fstab)

パーティション作成(前提)

パーティション設計が未整理なら、こちらを先に通すのが安全です。

ext4でフォーマット

mkfs.ext4 /dev/sdb1

XFSでフォーマット

mkfs.xfs /dev/sdb1

マウント(例:/data)

mkdir -p /data
mount /dev/sdb1 /data

/etc/fstab による永続化(UUID推奨)

blkid /dev/sdb1
# UUID="xxxx-...." TYPE="xfs" など

vi /etc/fstab
UUID=xxxx-....  /data  xfs  defaults  0  0

mount -a

LVM運用をしているなら、こちらも導線として非常に相性が良いです。

運用の鉄板チェック(拡張・修復・バックアップ)

① 拡張(特にXFS)

XFSはオンライン拡張が強みのひとつです(手順は要件に応じて)。

② 修復の考え方

  • ext4:fsck / e2fsck
  • XFS:xfs_repair

実務で詰まりやすい「検査/修復の観点」は以下も参照できます。

③ バックアップ方針

ファイルシステムの選定と同じくらい重要なのが「バックアップ設計」です。
スナップショット/LVM/rsyncなど、運用要件に合わせて整備してください(別記事化もおすすめ)。

よくあるトラブルと切り分け

1) 「空き容量があるのに書けない」→ inode枯渇の可能性

dfで空きがあっても、inodeが尽きると新規ファイルを作れません。

2) 「Read-only file system」になった

ストレージ/ファイルシステム異常やI/Oエラーで、保護のため read-only remount されることがあります。
まずは dmesg / syslog / SMART / ストレージ側アラート確認 → 影響範囲確認 → 復旧手順の順で進めます。

3) dfとduが一致しない

「消したはずのログをプロセスが掴んでいる」などが典型です(lsofで特定)。

FAQ

Q1. ext4とXFS、結局どっちが多い?
現場ではどちらも多いですが、ディストリ/運用標準で決まることが多いです。迷ったら ext4、RHEL系標準や大容量運用ならXFS、が基本線です。

Q2. ファイルシステム変更は後からできる?
基本は「作り直し(バックアップ→再フォーマット→復元)」が安全です。オンライン変換は事故りやすく、標準手順として推奨しません。

Q3. まず覚えるべき関連コマンドは?
df -T / lsblk -f / blkid / mount / du / lsof を押さえると、調査が一気に速くなります。

まとめ:

Linuxのファイルシステムは「仕組み(superblock/inode)」と「選定(ext4 vs XFS)」、そして「運用(確認/拡張/修復/障害)」まで一気に押さえると現場で強くなります。

目次