ディスク容量は空いているのに「No space left on device」と表示され、なぜ書き込めないのか落ち着いて原因を確かめようとしている一人運用の保守担当者
障害対応・運用監視約13分

ディスクは空きなのに書き込めない｜inode枯渇の見つけ方と対処

「ディスクがいっぱいです」とエラーが出た。あるいはログに No space left on device。あわてて df -h を打ってみたら——使用率はまだ余裕がある。

この「容量は空いているのに書き込めない」状況は、保守運用でいちばん混乱する障害のひとつですよね。容量を空けようと大きなファイルを探しても見つからず、原因がわからないまま時間だけが過ぎていく。頭の片隅で「これ、本当にディスクの問題なの？」という不安がふくらみます。

でも、落ち着いて大丈夫です。この症状の多くは、inode（アイノード）の枯渇という、はっきり原因のある状態です。容量（バイト数）ではなく、ファイルの「数」の上限に当たっているだけ。見る場所さえ分かれば、順番にたどって落ち着けます。

この記事では、df -i での確認から、どこが小さいファイルを大量に抱えているかの絞り込み、消してよいものの見極め、そして再発を防ぐ監視までを一緒に整理します。環境（ext4／XFSなど）で細部は変わりますが、「数の上限を疑って、どこに集まっているかを探す」という流れはそのまま使えます。

結論：まず df -i を打って、IUse%（inode使用率）が100%近くになっているパーティションがないかを見ます。あれば、原因は容量ではなく inode（ファイル数）の枯渇 です。次に、その中で 小さいファイルを大量に抱えているディレクトリを絞り込み（セッションファイル・キャッシュ・メール滞留・ログの破片などが定番）、中身と役割を確かめてから不要分を安全に減らします。そのうえで、掃除の自動化（ローテーション・期限削除）と df -i の監視を足して、同じ枯渇を繰り返さないようにします。あわてて何かを消す前に、まず「容量ではなく数だった」と正体を1つに絞るのが、結果的にいちばん早いです。

何が起きているか：inodeは「ファイル1つにつき1枚」の管理札

まず、正体をはっきりさせます。Linuxのファイルシステム（ext4など）では、ファイルやディレクトリ1つひとつに inode（アイノード） という管理情報の札が割り当てられます。ファイルの中身が入る「容量」とは別に、この管理札の総数にも上限があり、ext4などでは基本的にフォーマット（作成）時に決まって、後から簡単には増やせません。

ここが今回のポイントです。

つまり、df -h（容量）だけを見て「空いてるのに変だ」と悩むのは、片方のメーターしか見ていない状態なんです。もう一方の「数」のメーターを見れば、たいていは霧が晴れます。

どこから見るか：容量ではなく「数」のメーターを開く

容量（バイト数）のメーターとinode（ファイル数）のメーターは別物で、inode側が満杯だと容量が空いていても書き込めないことを示す図
容量と「数」は別のメーター。片方が空いても、もう片方が満杯なら書き込めない

順番はシンプルです。①数の枯渇かを確かめる → ②どこに集まっているかを絞る → ③安全に減らす → ④再発を防ぐ。手前から一段ずつ進みます。

① まず df -i で inode 使用率を見る

容量を見る df -h の代わりに、inode を見る df -i を打ちます。

ここで IUse% が100%近くなら、「容量ではなく数だった」と確定です。正体が分かった時点で、対処の半分は終わっています。逆に inode に余裕があるなら、原因は本当の容量不足や別の要因（後述）なので、そちらへ切り替えます。

ひと呼吸おきましょう。df -h だけを見て「空いてるのに書けない」と悩んでいた時間は、決して無駄ではありません。もう片方のメーターの存在を知っていれば、次からは最初の1分で正体にたどり着けます。

② 小さいファイルが集まっている場所を絞り込む

枯渇しているパーティションが分かったら、その中で inode（＝ファイル数）を大量に消費しているディレクトリを探します。容量ではなく「個数」を数えるのがコツです。

数の多い場所を1〜2か所に絞れれば、次は「それは消していいのか」の見極めです。

③ 中身と役割を確かめてから、安全に減らす

たまり場が分かっても、いきなり削除しないことが大事です。小さいファイルの群れの中に、消すと壊れるものが混ざっていることがあります。

削除して書き込めるようになったら、それは一次対処（急場をしのいだ状態）です。ここで終えず、④の再発防止まで続けるのが、同じ夜を繰り返さないコツです。

④ 再発を防ぐ：掃除の自動化と df -i の監視

inode枯渇は、一度起きた場所でまた起きやすい障害です。手で消して終わりにせず、仕組みで止めます。

具体例：「容量は6割なのに、突然メール送信でエラー」を追う

よくある一例を、順番に切り分けてみます。

もし最初に「容量が足りないのかも」と大きなファイル探しに時間を使っていたら、いつまでも原因にたどり着けなかったはずです。df -i で「数だった」と一手で切り替えられたからこそ、短い時間で本丸（滞留の原因）まで進めました。

影響：この障害を「知っている」だけで、夜が変わる

inode枯渇は、知らないと長く迷い、知っていれば数分で正体が分かる——差が極端に出る障害です。

逆に、この存在を知らないままだと、同じ「空いてるのに書けない」で毎回ふりだしに戻ります。今日この記事で正体を1つ知ったことが、次の当直の自分を助けます。

明日やること：自分の現場の inode を、平常時に見ておく

障害の最中ではなく、落ち着いている今のうちにできる、いちばん小さな一歩です。

  1. 担当サーバーで df -i を打って、各パーティションの IUse%（inode使用率） を控える。ふだんの値を知っておくだけでいい。
  2. その中で使用率が高め、または上がり続けていそうなパーティションがあれば、どのディレクトリにファイルが多いかをファイル数で軽く確認する。
  3. 定番のたまり場（セッション・キャッシュ・メール・ログの破片）に、古いものが消える仕組みが入っているかを見る。無ければ、掃除を1か所だけ足す。
  4. 監視に inode使用率のしきい値（例：80%）が入っているか確認する。容量だけ見ていたら、inodeも足す。
  5. 分かったこと（平常値・多いディレクトリ・掃除の有無）を、運用メモに1行残す。

全部を今日やらなくて大丈夫です。df -i を一度打って、自分の現場の平常値を知る——それだけで、次に「空いてるのに書けない」に出くわしたとき、迷わず正体にたどり着けます。

inode枯渇 切り分けチェックリスト

対応に着手するとき、これだけ確認できているかを見る項目です。コピーして自分のメモに当ててみてください。全部を毎回そろえる必要はありません。

まず外せない最低ラインはこの3つです。急いでいても、ここだけは押さえます。

次の項目は、原因を奥まで追うとき・再発を止めたいときに追加で確認します。当てはまらなければ飛ばして大丈夫です。

全部に○が付かなくても大丈夫です。最低ラインの「df -i を見たか」さえ押さえられれば、容量探しで消耗するより、ずっと確かな一歩になります。

よければ、こちらも

inode枯渇は、「たまり場を掃除し続ける仕組み」と「早めに気づく監視」があるほど、起きにくくなります。ディスク周りの備えとログの見方をセットにしておくと、この手の障害がだいぶ軽くなります。

inode枯渇が原因と突き止めて掃除と監視を入れ終え、正常に書き込めるようになったサーバー画面を見て安心している保守運用の担当者

「ディスクは空いているのに書き込めない」がこわいのは、エラーの言葉（容量）と本当の原因（数）がずれているからです。でも、df -i でもう一方のメーターを見ると決めるだけで、霧はかなり晴れます。多くの場合、あなたのサーバーがおかしいわけではなく、ただ小さなファイルが静かに増えて、数の上限に当たっていただけです。

今日は、落ち着いている今のうちに df -i を一度打って、自分の現場の平常値を知るところからで十分です。その一手が、次の「空いてるのに書けない」を、迷路ではなく手順に変えてくれます。

ほかの実務ヒントは記事一覧からどうぞ。保守運用の小さな備えを、メールでも少しずつお届けしています。

関連用語