【ITニュース解説】I Kept Deleting Logs for 48 Hours. The Inodes Were Already Gone.

あるシステム運用で「ディスクの空き容量がありません」というエラー（No space left on device）が発生した。これはシステムエンジニアがよく直面する問題の一つだが、今回は通常のディスク容量不足とは少し異なる、非常に厄介な状況だった。なぜなら、df -hコマンドで確認すると、ディスクにはまだ数ギガバイトもの空き容量があるにもかかわらず、わずか数キロバイトのファイルすら作成できなかったからだ。

この謎のエラーに直面した当初、多くの人がそうするように、まずはディスクの空き容量が本当に足りないと考えて対処した。システムエンジニアは、ログファイルが肥大化したり、不要なデータが溜まったりしてディスクを圧迫することがよくあると経験的に知っている。そのため、疑わしいログファイルや、システムが生成していた大量の小さなJSONファイルを削除する作業を始めた。例えば、: > ファイル名 コマンドでログファイルを空にしたり、du -shで大きなファイルを探して削除したりした。しかし、これらの対処を繰り返しても状況は改善せず、エラーは出続けた。

さらに悪いことに、状況はむしろ悪化した。ファイルを安全に削除しようと考え、「削除する前に一度ゴミ箱ディレクトリにコピーしてから元のファイルを消す」という方法を試したのだ。しかし、この方法は裏目に出た。コピー操作は一時的にファイルの数を倍増させ、ディスク上の「ある資源」をさらに速く消費させてしまったのである。

この「ある資源」こそが、今回の問題の核心である**inode（アイノード）**だ。inodeとは、ファイルシステムがファイルやディレクトリを管理するために使う、一種の「目録」や「管理票」のようなものだと考えると良い。各ファイルやディレクトリには、それぞれ固有のinodeが割り当てられており、そのファイルの名前、サイズ、所有者、アクセス権限、そしてディスク上のどこにデータが保存されているか、といった重要な情報が記録されている。ファイルシステムは、このinodeの数をあらかじめ決めていることが多く、いくらディスクに空き容量（データを保存する場所）があっても、このinodeの数が尽きてしまうと、新しいファイルやディレクトリをこれ以上作成できなくなるのだ。

今回のケースでは、システムが大量の非常に小さなJSONファイルや、Pythonのキャッシュディレクトリ（__pycache__など）、テストのキャッシュファイルなどを頻繁に生成していた。一つ一つのファイルはわずか数キロバイトで、du -shコマンドで確認しても合計サイズはそれほど大きく見えなかったため、ディスク容量を圧迫しているようには見えなかった。しかし、ファイルが小さくても大きくても、ファイルを一つ作成するたびにinodeが一つ消費されるという事実は変わらない。結果として、ディスクのデータ保存領域は残っているのに、ファイルを管理するための目録（inode）だけが先に枯渇してしまい、新しいファイルが作れないという奇妙な状況に陥っていたのである。

このinode枯渇の真の原因に気づくまで、実に二日近くもかかってしまった。最終的に、df -iコマンド（df -hがディスク容量を表示するのに対し、df -iはinodeの使用状況を表示するコマンド）を実行したところ、システムのあるマウントポイントでinodeの使用率がほぼ100%に達していることが判明した。これにより、初めて問題の根源が明らかになったのである。

inode枯渇の原因が判明した後、対応は比較的スムーズに進んだ。findコマンドなどを活用して、どのディレクトリにファイルが大量に存在するのか、どのような種類のファイルがinodeを消費しているのかを調べた。すると、やはりPythonのキャッシュディレクトリやJSONサイドカーファイルなど、当初は「サイズが小さいから」と見過ごしていた部分に大量のファイルが集中していることがわかった。

この経験から得られた教訓は非常に多い。まず、ディスク関連のエラーが発生した際には、df -hでディスク容量を確認するだけでなく、必ずdf -iでinodeの使用状況も同時に確認するべきだということがわかった。この二つのコマンドは、それぞれ異なる種類の「空き容量」を教えてくれるため、どちらか一方だけでは全体像を把握できないことがある。

また、ファイルを削除する際のアプローチも見直す必要がある。特に大量の小さなファイルがある場合、「コピーしてから削除する」という方法は、一時的にinodeの使用数を倍増させるため、状況をさらに悪化させる可能性がある。このような場合は、直接ファイルを削除するか、あるいはゴミ箱ディレクトリを別のファイルシステム上に配置するなどの工夫が必要になる。

さらに、アプリケーションのエラーログ出力も改善すべき点として挙げられる。エラーメッセージの文字列だけでは、今回のように原因が誤って解釈されてしまうことがあるため、エラー番号（errno）を明示的に出力するように変更した。これにより、将来的に No space left on device（ENOSPC）と Too many open files（EMFILE）のように、似たような状況を引き起こす可能性のある異なる種類のエラーを正確に区別できるようになる。

このような経験を二度と繰り返さないために、ディスク関連のエラーが発生した際に、ディスク容量、inode使用状況、ディレクトリ内のファイル密度、オープンファイル数といった、複数の観点からシステムの健康状態を一度にチェックできる診断スクリプトも作成した。このスクリプトは読み取り専用で、何も変更せずに現在の状況を報告する。そして、その結果に基づいて、人間が適切な対処法を判断するための「決定表」も用意した。これにより、パニック状態でも冷静かつ体系的に問題の原因を探れるようになった。

最近の技術トレンドであるAIモデルの活用についても、この経験は示唆に富んでいた。AIモデルに診断スクリプトのドラフトを依頼したところ、有用な提案を得られたが、一方で「クリーンアップスクリプト」を依頼した際には、今回の問題を悪化させた「コピーしてから削除する」パターンを提案したという。このことから、AIモデルを利用する際には、明確かつ具体的な指示を与え、特にファイル操作のような影響が大きい処理については慎重に判断する必要があることがわかった。

今回の問題は、単に「ディスクがいっぱい」という単純な話ではなかった。システムエンジニアがディスク容量という物理的なリソースを管理する際に、その裏でファイルシステムがどのようにファイルを管理しているか、というメタデータのリソースであるinodeの存在を忘れてはならないという、重要な学びがあった。数キロバイトの小さなファイルも、それが何万、何十万と積み重なれば、ディスクの容量だけでなく、inodeという目録の数を圧迫し、最終的にはシステムの動作を停止させる原因となるのだ。これからは、ログファイルやサイドカーファイルのような小さなファイルも、そのサイズだけでなく、「数」という観点からもしっかりと管理していく必要がある。df -hとdf -i、この二つのシンプルなコマンドを常に意識し、エラーの際にはerrnoを確認する。これが、二日間の苦闘から得られた最も価値のある教訓である。