「ゴースト」スペース問題
非常に厄介な状況です。df -hでディスクを確認すると50GBの空きがあるのに、ファイルを保存しようとするたびにLinuxがNo space left on deviceとエラーを返します。これは通常、**iノード（Inode）**を使い果たしたことを意味します。
iノードは、ファイルシステムのデータベースにおける「レコード」のようなものだと考えてください。すべてのファイル、ディレクトリ、シンボリックリンクは、それぞれ1つのiノードを必要とします。もしファイルシステムが100万個のiノードを扱えるようにフォーマットされており、100万個の小さなファイルを作成してしまったら、たとえ物理的な空き容量が500GB残っていても、1,000,001個目のファイルを作成することはできません。
1. iノード不足の確認
標準的なディスクチェックでは、iノードの使用状況は表示されません。代わりに-iフラグを使用する必要があります。
df -i
IUse%列を確認してください。パーティションの使用率が99%または100%と表示されている場合、限界に達しています。標準的な20GBのExt4パーティションでは、通常約130万個のiノードがあります。これらがなくなると、システムは完全に停止します。
2. 大量のファイルを抱え込んでいる場所を特定する
次に、数百万ものファイルがどこに隠れているかを見つける必要があります。通常、これは1つの巨大なファイルではなく、数百万個の0KBまたは1KBの小さなファイルです。ディレクトリごとのファイル数をカウントするために、次のコマンドを実行します（低速なディスクでは数分かかる場合があります）。
sudo find / -xdev -printf '%h\n' | sort | uniq -c | sort -k 1 -n | tail -n 20
このコマンドは、ファイル数が多い上位20個のディレクトリをリストアップします。50万個以上のファイルを含むディレクトリが見つかれば、それが原因です。
3. 不要ファイルを一掃する
ディレクトリに数百万ものファイルが含まれている場合、rm *を実行すると「Argument list too long（引数リストが長すぎます）」エラーで失敗する可能性が高いです。これは、シェルが一度にそれほど多くの引数を処理できないために起こります。findを使用して、安全に一括削除します。
sudo find /path/to/bloated/dir -type f -delete
よくある原因と実例
なぜこのようなことが起こるのでしょうか？通常、バックグラウンドプロセスやアプリの設定ミスが原因です。一般的なWebサーバーでは、以下のようなケースがよく見られます。
- 放置されたPHPセッション：
php.iniでクリーンアップ設定が適切でない場合、/var/lib/php/sessionsに200万個もの小さなファイルが蓄積されることがあります。 - Maildropの悪夢： ローカルシステムのメール送信が正常に機能していない場合、
/var/spool/postfix/maildropが数十万個の小さなエラー通知で埋め尽くされることがあります。 - 管理されていないマイクロサービス： DockerコンテナやNode.jsアプリが、ローテーションされない大量の小さな一時キャッシュファイルやログを生成している場合があります。
- 深くネストされたディレクトリ： 自動ビルドツールが古いバージョンをクリーンアップせずに、膨大な依存関係ツリーを作成してしまうことがあります。
高度な復旧方法
方法1：選択的な削除
最新のデータは保持しつつ、3日以上前のセッションファイルなどの古い不要ファイルのみを削除したい場合は、次のコマンドを使用します。
sudo find /var/lib/php/sessions -type f -mtime +3 -delete
方法2：Postfixキューのクリア
メールスプールがボトルネックになっている場合は、手動でファイルを削除するのではなく、専用のツールを使用して安全にキューをクリアしてください。
sudo postsuper -d ALL
方法3：ゴーストファイル記述子の追跡
数百万のファイルを削除しても、依然としてdf -iが100%の使用率を示すことがあります。これは、実行中のプロセス（NginxやApacheなど）がまだそれらのファイルを開いたままにしているために起こります。Linuxカーネルは、プロセスがファイルを閉じるまでiノードを解放しません。これらの「ゴースト」ファイルは以下の方法で見つけることができます。
sudo lsof | grep deleted
削除済みのファイルを数千個も保持し続けているサービスがある場合は、そのサービスを再起動して強制的にiノードを解放させます。
sudo systemctl restart [service_name]
再発を防ぐ方法
クリーンアップは解決策の半分に過ぎません。再発を防ぐために、以下の3つの対策を講じてください。
- Logrotateの修正： ログが圧縮され、一定期間後に削除されるように設定してください。ローテーション設定のないログディレクトリは、1ヶ月で10万個のiノードを消費することがあります。
- iノードのアラート設定： 多くの監視ツール（NagiosやZabbixなど）はディスク容量（GB）のみを監視します。
df -iが80%に達したときに通知が来るよう、アラート設定を更新してください。 - Cronジョブの確認： 自動スクリプトにクリーンアップの手順が含まれているか確認してください。毎分一時ファイルを作成するスクリプトは、1年間で525,600個のiノードを消費します。