【AlmaLinux 10】ストレージ・ファイルシステム管理トラブルシューティング完全ガイド：容量枯渇とマウント異常の解決

サーバーインフラストラクチャの運用において、CPUやメモリと並び、あるいはそれ以上にシステムの生死を直結させるのが「ストレージおよびファイルシステム」の管理です。ログファイルの肥大化によるディスク容量の枯渇、大量の小ファイル生成によるinodeの枯渇、あるいは /etc/fstab の記述ミスに起因する起動時のマウント異常など、ストレージ関連のトラブルはシステムを完全に沈黙させる最も強力なトリガーとなります。

RHEL 10系をベースとする最新のAlmaLinux 10では、XFSやext4といった堅牢なファイルシステムが標準でサポートされていますが、物理・仮想を問わず、運用フェーズにおけるリソース管理の不備が原因で障害が発生するリスクは常に存在します。

本記事では、AlmaLinux 10環境におけるストレージ・ファイルシステム管理に焦点を当て、容量逼迫・inode枯渇の特定から、fstabミスによる緊急モードからの生還、そしてファイルシステムの健全性を保つための実践的なトラブルシューティング手順を徹底解説します。

---

1. トラブル①：ディスク容量枯渇（Disk Full）の原因特定と即時解放

システムが突然動作不良を起こしたり、ログの出力が停止した場合、多くはルートパーティション（/）などのディスク容量が100%に達している（Disk Full）ことが原因です。

1.1. パーティション使用状況の可視化（dfコマンド）

まずはどのマウントポイントが圧迫されているかを迅速に確認します。

# ファイルシステムの容量と使用率を人間が読みやすい単位（-h）で確認
df -h

もし使用率が 100% になっているパーティションが見つかった場合、次に「どのディレクトリやファイルが容量を大量に消費しているのか」を特定します。

# ルート直下で、容量を食っている上位ディレクトリを検索
sudo du -h --max-depth=1 / | sort -hr

1.2. ゾンビファイル（削除済みだがプロセスが掴んでいるファイル）の罠

ログファイルを rm コマンドで削除したにもかかわらず、ディスクの空き容量（dfの数値）が増えないというトラブルは、インフラの現場で頻発します。
これは、バックグラウンドのサービス（例：rsyslogやnginx）がそのファイルを開きっぱなし（オープン状態）にしているため、OSが「プロセスがまだ使っているから実体は消せない」と判断し、ディスク領域を解放していないためです。

# 削除されたにもかかわらずオープンされている「ゾンビファイル」を検出する
sudo lsof +L1

該当するプロセスを特定して再起動（例：sudo systemctl restart nginx.service）させることで、プロセスがファイルを完全に閉じ、ディスク容量が瞬時に解放されます。

2. トラブル②：容量に余裕があるのに「No space left on device」が出るinode枯渇

df -h で確認したところディスク容量にはまだ数十GBの空きがあるにもかかわらず、ファイルを作成しようとすると No space left on device とエラーが出て弾かれる現象があります。これは「inode（アイノード）の枯渇」が原因です。

2.1. inodeとは何か？なぜ枯渇するのか

inodeは、Linuxのファイルシステムにおいて「ファイルやディレクトリのメタデータ（所有者、パーミッション、データブロックの場所など）」を管理する構造体です。ファイルシステム作成時に総数が固定されます。

「数KB程度の非常に小さなファイルを何百万個も生成するアプリケーション（メールスプール、セッションファイル保存ディレクトリ、キャッシュなど）」を運用していると、ディスクの総容量（GB）に余裕があっても、inodeの総数（個数）が100%に達してしまう事態が発生します。

# inodeの使用状況を確認する
df -i

もし「IUse%」が 100% になっているファイルシステムがある場合、容量ではなくinodeが原因で書き込みが拒絶されています。
解決策としては、不要な小ファイル群をバッチ的に削除する、あるいはアプリケーション側のキャッシュ設計を見直してセッション等をファイルではなくRedis等のインメモリに逃がすアーキテクチャへの変更が必要です。

3. トラブル③：fstabの設定ミスによる起動時の「Emergency mode」突入と修復

追加のストレージやNFS共有などを /etc/fstab に記述した際、UUIDのタイポ、ファイルシステムタイプの誤り、あるいは存在しないデバイスを指定して再起動を行うと、AlmaLinux 10は起動プロセス途中でマウントに失敗し、安全のために「Emergency mode」へと突入します。

3.1. fstabの不整合を修正する手順

Emergency modeのシェルに入ったら、原因となった /etc/fstab の記述ミスを修正します。

# 1. 読み取り専用でマウントされているルートファイルシステムを「読み書き可能（rw）」に再マウント
sudo mount -o remount,rw /

# 2. 原因となった /etc/fstab をエディタ（vi等）で開く
sudo vi /etc/fstab

# 3. 直近で追加・変更し、マウントエラーを引き起こした該当行をコメントアウト (#) または修正する
# 例：UUID=xxxx-xxxx-xxxx /mnt/data ext4 defaults 0 0  <-- ここが間違っている場合

修正を保存したら、変更が正しく反映されているかを検証するためにシステムを再起動します。

# システムの再起動
sudo reboot

4. トラブル④：XFSファイルシステムの破損とxfs_repairによる修復

突然の電源断（ハードウェアの強制シャットダウン）や仮想基盤のホスト障害が発生した場合、AlmaLinux 10のデフォルトファイルシステムであるXFSがメタデータの不整合を起こし、起動時にマウントエラーを引き起こすことがあります。

4.1. xfs_repairを用いたファイルシステム修復

もし特定のデータパーティション（例：/dev/sdb1）が破損してマウントできない場合、シングルユーザーモード等から xfs_repair コマンドを実行して修復を試みます。

# 破損したXFSファイルシステムをチェック・修復する
sudo xfs_repair /dev/sdb1

※注意：xfs_repair を実行する対象のパーティションは、必ず「アンマウント（マウントされていない状態）」でなければなりません。ルートパーティション（/）自体が破損している場合は、AlmaLinux 10のインストールメディアやレスキューモード（救援モード）でブートして外部から修復作業を行う必要があります。

5. まとめとストレージ運用のベストプラクティス

本記事では、AlmaLinux 10環境におけるストレージおよびファイルシステム管理のトラブルシューティングとして、以下の4つの主要な障害と修復手法を解説しました。

• ディスク容量枯渇（Disk Full）： df -h と du による逼迫箇所の特定、および lsof +L1 を用いたゾンビファイルの解放。
• inode枯渇： df -i による確認と、小ファイルの大量生成が引き起こす書き込みエラーのメカニズム。
• Emergency modeからの生還： /etc/fstab の記述ミスによる起動失敗時のルート再マウント（mount -o remount,rw /）と設定修正。
• XFSファイルシステムの修復： 突然の電源断等によるメタデータ破損に対する xfs_repair の適用。

ストレージのトラブルはデータLossに直結する最もクリティカルな事象です。日頃から監視基盤を用いてディスク使用量やinode使用率のトレンドを監視し、アラート設定を行っておくことが、エンタープライズインフラを護る最高の安全対策となります。