ファイルシステムの不整合を次回起動時に検査・修復させる実務手順

強制電源断やストレージ障害が起きた直後、journalctl -b -p err や dmesg | grep -i error でファイルシステムエラーが出ていることがあります。放置するとデータ破損が拡大する前段階に入ることがあるため、早期に検査・修復しておくことが重要です。

ただし、OS が稼働中にマウントしているパーティション（とくに root /）には fsck を直接実行できません。本記事では ext4・XFS それぞれの安全な実行方法と、次回起動時に root パーティションを強制検査させる手順を、systemd 世代の現代 Linux に合わせて解説します。

非 root パーティションはアンマウントして即時検査する

データ用パーティション（/data など）が対象であれば、アンマウントしてからそのまま検査・修復ツールを実行できます。まず対象パーティションとファイルシステムの種類を確認します。

# マウント状況とファイルシステム種別を確認
lsblk -f
findmnt /data

ext4 の場合は、利用中のサービスを止めてからアンマウントし、fsck を実行します。

# アンマウント
sudo umount /dev/sdb1

# ext4 を強制フルチェック（-f: 強制, -y: エラーを自動修正）
sudo fsck -fy /dev/sdb1

XFS の場合は fsck ではなく xfs_repair を使います。fsck は XFS の修復には対応していません。

sudo umount /dev/sdb1

# まず読み取り専用で問題を確認（-n: 変更なし）
sudo xfs_repair -n /dev/sdb1

# 問題があれば修復を実行
sudo xfs_repair /dev/sdb1

注意：xfs_repair で「dirty log」エラーが出た場合は、一度マウント→アンマウントすることでジャーナルが再生されます。それでも解消しない場合にのみ -L（ジャーナル強制削除）を使ってください。-L は最終手段です。

ext4 の root パーティションを次回起動時に強制検査させる

root パーティションは稼働中にアンマウントできないため、次回起動の initramfs フェーズで fsck を走らせます。tune2fs で「マウント回数のチェック条件を意図的に満たす」設定をしてから再起動するのが確実な方法です。

まず現在の設定を確認します。

# 現在のマウント回数と上限を確認
sudo tune2fs -l /dev/sda1 | grep -E "Mount count|Maximum mount count"

RHEL 8/9・AlmaLinux・Ubuntu 22.04 以降では、デフォルトで最大マウント回数が -1（無効）になっていることが多く、通常は回数ベースの自動 fsck は走りません。以下の手順で「次回起動時に必ず検査する」よう設定します。

# マウント回数上限を 1 に設定し、現在のカウントを 0 にリセット
# → 次回起動時に 1 回マウントした時点で条件を満たし fsck が走る
sudo tune2fs -c 1 -C 0 /dev/sda1

# 設定を確認してから再起動
sudo tune2fs -l /dev/sda1 | grep -E "Mount count|Maximum mount count"
sudo systemctl reboot

fsck 完了後、次回起動で再び fsck が走ることを防ぐため、マウント回数の上限を元に戻しておきます。

# fsck 後、マウント回数チェックを無効に戻す
sudo tune2fs -c -1 /dev/sda1

カーネルパラメータで一度だけ強制検査を走らせる方法

tune2fs を使わずに、GRUB のカーネルパラメータで次回起動のみ fsck を強制実行する方法もあります。ファイルシステムの種類を問わず有効です。

GRUB 起動メニューで対象エントリを選び、e キーで編集モードに入ります。linux 行の末尾に以下を追加して Ctrl+x で起動します。

fsck.mode=force fsck.repair=yes

この変更は一時的なもので、/etc/default/grub は書き換わりません。通常の次回起動から影響を受けることなく使えます。

注意：恒久設定として /etc/default/grub に書き込んだ場合は、検査後に必ず削除してください。残したままにすると起動のたびに全パーティションの fsck が走り、大規模環境では起動時間が大幅に延びます。

XFS の root パーティションを修復する場合はレスキューモードを使う

XFS は fsck.mode=force を指定しても xfs_repair が自動実行されません。XFS の root パーティションに深刻な問題がある場合は、OS インストールメディアや RHEL のレスキューモードで起動し、xfs_repair を手動実行します。

# レスキューシェルでの修復手順例（/dev/sda2 が XFS root の場合）

# 読み取り専用で状態確認
xfs_repair -n /dev/sda2

# 問題があれば修復を実行
xfs_repair /dev/sda2

検査結果の確認と次のアクション

起動後、fsck の実行ログは journalctl で確認できます。

# 今回の起動で実行された fsck のログを確認
journalctl -b 0 -u systemd-fsck-root.service
journalctl -b 0 -u "systemd-fsck@*"

# ストレージ関連のエラー・警告を一覧する
journalctl -b 0 -p warning -g "ext4|xfs|fsck|blk"

fsck の終了コードは意味を持っています。0 はエラーなし、1 は修正あり・正常終了、2 はシステム再起動が必要、4 以上は未修正のエラーが残った状態です。終了コード 4 以上が返ってきた場合は、ファイルシステム修復だけでは解消しない可能性があります。ハードウェア起因のエラーを疑い、SMART 値を確認します。

# ディスク健全性の確認（smartmontools が必要）
sudo smartctl -H /dev/sda
sudo smartctl -a /dev/sda | grep -E "Reallocated|Pending|Uncorrectable"

ある運用現場では、fsck -y による自動修正が誤ったブロックを上書きし、本来であれば復元できたファイルを失ったケースがあります。SMART ステータスが FAILED を示している場合や、エラーブロックが多い場合は、fsck -n（読み取り専用）で影響範囲を把握し、バックアップを確保してから修復に臨むことをお勧めします。LVM 環境であれば事前スナップショットが比較的安全に取得できます。

# LVM スナップショットの例（事前に空き容量を確認すること）
sudo lvcreate -L 10G -s -n snap_data /dev/vg0/data