Linuxでinode枯渇問題の原因と対処

Linuxサーバーで「ディスク容量はまだ空いているのにファイルが作れない」「No space left on device が出るのに df -h では余裕がある」という状態に遭遇したとき、まず疑うべきなのが inode 枯渇になる。これは容量不足とは別の問題で、ファイルやディレクトリを管理するための inode が使い切られている状態を指す。特に、小さなファイルを大量に作るアプリケーション、キャッシュ、メール、ログ、コンテナ、セッションファイルなどがある環境では起こりやすい。この記事では、inode とは何か、なぜ枯渇するのか、どう確認し、どう対処し、どう再発防止するかを順番に整理する。

inodeとは何か

Linuxのファイルシステムでは、ファイルやディレクトリそのものの中身とは別に、それらを管理するための情報を inode という単位で持っている。
inodeには、
・所有者
・権限
・サイズ
・タイムスタンプ
・データの場所
などが記録される。
つまり、1つのファイルやディレクトリを1つの管理情報として扱うための入れ物が inode と考えると分かりやすい。
そのため、ディスク容量が十分に残っていても、inode が無くなると新しいファイルを作れなくなる。

inode枯渇とは何か

inode枯渇とは、ファイルシステム上で利用可能な inode 数を使い切ってしまった状態を指す。
この状態になると、空き容量が残っていてもファイルやディレクトリの新規作成ができなくなる。
典型的には、
・アプリが一時ファイルを大量生成する
・キャッシュファイルが増え続ける
・メールキューやログが細かいファイルで大量に溜まる
・コンテナやセッションファイルが大量に残る
といったケースで起こりやすい。

よくある症状

inode枯渇では、次のような症状が出やすい。
・No space left on device が出る
・ファイル作成や保存が失敗する
・アプリケーションのキャッシュ生成が失敗する
・メール配送やジョブ処理が止まる
・ログローテーションに失敗する
ここで紛らわしいのは、メッセージだけ見ると普通の容量不足に見えること。
しかし df -h では空きがあるのに書けない場合、inode を疑う方が早い。

まずは df -i でinode使用率を確認する

inode問題の確認では、最初に df -i を使う。
これは容量ではなく inode の使用状況を見るコマンド。

df -i

ここで見るポイントは、
・IUsed
・IFree
・IUse%
の3つ。
特に IUse% が 100% に近い、または 100% なら、そのファイルシステムでは inode 枯渇が起きている可能性が高い。
df -h と df -i をセットで見ると、容量不足か inode 不足かを切り分けやすい。

df -h と df -i の違いを混同しない

容量問題と inode 問題は別物。
df -h は容量の使用率を見る。
df -i は inode の使用率を見る。
たとえば次のように両方確認すると分かりやすい。

df -h
df -i

もし、
・df -h では空きがある
・df -i では 100% 近い
なら、容量ではなく inode が尽きていると考えやすい。
この2つを見分けるだけで、調査の方向がかなり早く決まる。

なぜinodeが枯渇するのか

inode 枯渇の本質は、「小さなファイルが異常に多い」ことにある。
1つ1つは数KBや数バイトしか使っていなくても、ファイル1個につき inode を1つ消費するため、数が多ければ inode は先に尽きる。
代表例としては、
・キャッシュディレクトリ
・セッションファイル
・メールスプール
・監視ツールの細かいデータファイル
・展開された大量のソースファイル
・画像やサムネイルの大量生成
などがある。
大容量の単一ファイルより、小さなファイルの大量発生の方が危険になりやすい。

どのディレクトリにファイルが大量にあるかを探す

inode 枯渇が疑われたら、次は「どのディレクトリにファイルが偏っているか」を探す。
まずはトップレベルの件数感を掴む方法が使いやすい。

for dir in /*; do echo “$dir”; find “$dir” | wc -l; done 2>/dev/null

ただしこれはかなり重いことがあるため、対象ファイルシステムの中で怪しい場所から絞る方が現実的。
たとえば /var が怪しければ、次のように見る。

for dir in /var/*; do echo “$dir”; find “$dir” | wc -l; done 2>/dev/null

これで、どの配下に異常に多くのファイルやディレクトリがあるかを見つけやすい。

ファイル数が多い場所を絞り込む方法

より実務的には、階層を一段ずつ下りながら怪しい場所を探す方が安全。
たとえば /var の中で件数が多い場所を見つけたら、その下をさらに見る。

for dir in /var/log/*; do echo “$dir”; find “$dir” | wc -l; done 2>/dev/null

あるいは /tmp や /var/tmp もよく疑う。

find /tmp | wc -l
find /var/tmp | wc -l

このように段階的に絞ると、
・キャッシュ
・ログ
・セッション
・メール
など、犯人ディレクトリを特定しやすい。

小さいファイルが大量にある場所を見つける考え方

inode 枯渇では、容量ではなく数が問題なので、サイズより件数を見る方が重要。
たとえば /var/cache や /var/lib 配下に、何十万件ものファイルがあるとかなり怪しい。
容量確認の du -sh だけでは見えにくいため、件数とセットで見ると判断しやすい。

du -sh /var/cache/*
for dir in /var/cache/*; do echo “$dir”; find “$dir” -type f | wc -l; done 2>/dev/null

「サイズは小さいのにファイル数だけ極端に多い」場所が、inode 枯渇の原因になりやすい。

よくある犯人ディレクトリ

inode 枯渇で特に疑いやすい場所は次のようなもの。
・/tmp
・/var/tmp
・/var/log
・/var/spool
・/var/cache
・アプリの upload / cache / session ディレクトリ
・Docker / コンテナ関連の一時領域
・メールキューや監視データ保存領域
特に /tmp やアプリのキャッシュ系は、開発環境でも本番環境でもかなり起こりやすい。
不要ファイルが消されない設計だと、容量より先に inode を使い切ることがある。

応急処置として何を消すべきか

原因ディレクトリが見つかったら、まずは不要なファイルを削除して inode を回復させる。
ただし、いきなり広範囲を消すのではなく、
・明らかに一時ファイル
・古いキャッシュ
・すでに不要なログ
・再生成可能な中間ファイル
から削除する方が安全。
たとえば /tmp 配下の古いファイルを対象にする例は次のような形。

find /tmp -type f -mtime +7 -delete

ただし、本番環境ではそのディレクトリの用途を確認せずに削除しない方がよい。
「消してよい一時ファイル」かどうかの確認が先になる。

ログやキャッシュの整理方法

ログやキャッシュが原因なら、まず現在の件数を確認し、その後ローテーションや削除方針を見直す。
たとえばログ件数確認。

find /var/log -type f | wc -l

キャッシュ系確認。

find /var/cache -type f | wc -l

単に今消すだけでなく、
・ログローテーションが効いているか
・アプリが古いキャッシュを掃除する仕組みを持っているか
・一時ファイルを定期削除する運用があるか
を後で見直さないと再発しやすい。

Dockerやアプリ環境で起こりやすいケース

最近の環境では、コンテナやアプリケーションランタイムが inode を食い尽くすことも多い。
たとえば、
・大量の小さなレイヤファイル
・コンテナログ
・キャッシュディレクトリ
・セッションファイル
・ジョブワーカーの一時出力
などがある。
Webアプリでは、ファイルアップロードよりも、小さな一時ファイルやセッションファイルの方が inode 問題の原因になりやすいこともある。

再発防止のために見るべきこと

inode 枯渇は、今のファイルを消すだけでは不十分なことが多い。
再発防止のためには、次のような観点が重要。
・ファイルを大量生成する処理がないか
・ログローテーションは正常か
・キャッシュ削除の仕組みがあるか
・一時ファイルが残り続けていないか
・監視対象に inode 使用率を入れているか
つまり、「なぜ増えたのか」を潰さないと再び同じ問題になる。

監視対象に inode を入れる重要性

容量監視だけでは inode 枯渇を見逃しやすい。
そのため、監視では df -i ベースの inode 使用率も対象にする方が安全。
少なくとも、
・IUse% が高いファイルシステム
・ログやキャッシュが多いマウントポイント
は継続監視した方がよい。
「ディスク使用率は正常なのに書けない」という障害を防ぐには、容量と inode を分けて監視する必要がある。

ファイルシステム作成時の inode 設計にも注意する

inode 数はファイルシステム作成時の設計にも影響される。
環境によっては、後から簡単には変えられないことがある。
そのため、最初から
・小さいファイルを大量に置く用途なのか
・大きいファイル中心なのか
を意識してファイルシステムを設計する方がよい。
メールサーバーやキャッシュサーバーのように小ファイルが多い用途では、一般用途より inode 設計が重要になりやすい。

よくある失敗と勘違い

inode 問題でよくある失敗はかなり典型的。
・df -h だけ見て容量不足ではないと安心する
・No space left on device を容量問題だけだと思い込む
・サイズの大きいファイルばかり疑う
・件数ではなく容量だけを見ている
・原因ディレクトリを特定せずに広範囲削除する
・応急処置だけで再発防止をしない
特に、「ディスク空きがあるから関係ない」と思って inode を見ないのが最も多い失敗になる。

実務で進めやすい確認手順

inode 枯渇を疑ったとき、進めやすい順番は次の通り。

1. df -h と df -i を比較する
2. inode 使用率が高いファイルシステムを特定する
3. その配下で件数の多いディレクトリを探す
4. 不要ファイルを慎重に削除する
5. ログ、キャッシュ、一時ファイルの増え方を確認する
6. 監視と削除運用を見直す
   この流れで進めると、容量不足との混同を避けつつ、原因ディレクトリと再発防止策までつなげやすい。

まとめ

Linuxで inode 枯渇問題を理解するうえで重要なのは、
・inode はファイルやディレクトリを管理するための単位であること
・容量不足とは別に、inode 不足でもファイル作成が失敗すること
・確認には df -i を使うこと
・原因は小さなファイルの大量発生であることが多いこと
・対処は不要ファイル削除と再発防止の両方が必要なこと
このあたりになる。
「空き容量はあるのに書けない」という現象に遭遇したら、まず inode を疑うだけで原因特定がかなり速くなりやすい。
容量監視だけでなく inode 監視も含めて運用することが、再発防止ではかなり重要になる。