ディスク満杯の調査と対処
「書き込めない」「サービスが起動しない」障害の典型原因がディスク満杯です。まず df -h で各マウントポイントの使用率を見て、100%に近い領域を特定します。次に du で原因のディレクトリを上から掘り下げ、肥大化したファイルを突き止めます。よくある犯人は伸び続けるログファイルや古いキャッシュです。なお、削除してもプロセスがファイルを開いたままだと容量が戻らないことがあり、その場合は lsof で開いているプロセスを確認します。
「ファイルに書き込めない」「サービスが急に起動しなくなった」「ログが記録されない」——こうした一見バラバラな障害の、意外なほど多くの共通原因がディスク満杯です。ディスクの空きが尽きると、プログラムは新しいファイルを作れず、既存ファイルへの追記もできなくなるため、影響が思わぬところに飛び火します。しかもエラーメッセージが直接「ディスクが満杯です」と言ってくれるとは限らず、別の症状として現れることも多いので、原因不明の不調に出会ったら、ディスク使用量の確認を切り分けの早い段階に入れておくと近道です。
df で満杯の領域を特定する
まず全体像を df で確認します。df は disk free の略で、ファイルシステム（マウントされた各領域）ごとの容量と使用状況を一覧します。df -h と人間に読みやすい単位を付けて実行すると、Filesystem（デバイス名）、Size（総容量）、Used（使用量）、Avail（空き）、Use%（使用率）、Mounted on（マウント先のパス）が表形式で並びます。ここで Use% が100%、あるいはそれに近い領域を探します。たとえば / が100%なのか、/var だけが満杯なのか、/home が逼迫しているのかで、次に掘る場所が決まります。Linuxは複数のディスクや領域を別々のパスにマウントできるため、「全体ではまだ空いているのに、特定の領域だけ満杯」というケースがよくある点に注意します。
du で原因のディレクトリを掘り下げる
満杯の領域が分かったら、その中の「何が」容量を食っているかを du で突き止めます。du は disk usage の略で、ディレクトリが使っている容量を集計します。やみくもに使うと出力が膨大になるので、上の階層から順に掘り下げるのがコツです。たとえば du -h --max-depth=1 /var のようにすると、/var の直下にある各ディレクトリの合計サイズが1段だけ表示され、どこが大きいかが分かります。一番大きいディレクトリ（たとえば /var/log）が見つかったら、今度はそこを対象に同じコマンドを実行し、さらに一段深く掘ります。これを繰り返して、肥大化したファイルやディレクトリへ絞り込んでいきます。大きい順に並べたいときは du -h --max-depth=1 /var | sort -h のように sort -h（人間可読な単位でソート）をつなぐと見やすくなります。
よくある犯人は、伸び続けるログファイル（とくにログローテーションが効いていないアプリのログ）、溜まり続ける古いキャッシュや一時ファイル、肥大化したデータベースのファイル、消し忘れた巨大なバックアップやダンプファイルなどです。du で大きなファイルを特定できたら、本当に消してよいものかを確認したうえで、不要なものを削除したり、ログをローテーション・圧縮したりして空きを取り戻します。なお、ディスクが満杯に近づくと書き込みが詰まり、システム全体の性能を頭打ちにするボトルネックにもなり得ます。容量の確保は、単に「書けるようにする」だけでなく、性能面でも効いてくる対処だと捉えておくとよいでしょう。
消したのに容量が戻らない——削除済みファイルとファイルディスクリプタ
ディスク満杯対応で初学者が必ずと言ってよいほどはまる落とし穴があります。大きなログファイルを rm で削除したのに、df を見ても空きがまったく増えない、という現象です。原因はLinuxのファイルの扱い方にあります。あるプロセスがファイルを開いている（読み書きのために掴んでいる）と、そのファイルへの参照が「ファイルディスクリプタ」という形で保持されます。ファイルディスクリプタとは、プロセスが開いているファイルやソケットに割り当てられる管理番号のことです。ファイル名を rm で消しても、それを開いたままのプロセスが残っていると、ディスク上の実体は解放されず、容量も戻りません。実体が本当に消えるのは、最後にそのファイルを開いていたプロセスがファイルを閉じる（または終了する）瞬間です。
この状態を確認するのが lsof（list open files）です。lsof +L1 とすると、「削除済みなのにまだ開かれているファイル」を一覧でき、どのプロセス（とPID）がそれを掴んでいるかが分かります。原因のプロセスが特定できたら、そのプロセスを再起動するか、安全に終了させると、掴んでいたファイルが解放され、ようやくディスクの空きが戻ります。サービスのログでこれが起きている場合は、サービスを再起動するか、ログのローテーション時にサービスへログの開き直しを通知する仕組み（多くは logrotate の設定）を整えるのが正攻法です。「消したのに減らない」を知っているだけで、無駄に悩む時間を大きく減らせます。
inode 枯渇という別の満杯
もうひとつ知っておきたいのが、容量はまだあるのに「書き込めない」ケースです。ファイルシステムは、ファイルの実データとは別に、1ファイルにつき1つ「inode」という管理情報の枠を消費します。小さなファイルが極端に大量にあると、データ容量より先にこの inode を使い切ってしまい、空きはあるのにファイルを作れなくなります。df -h で Use% に余裕があるのに書き込めないときは、df -i で inode の使用率（IUse%）を確認します。ここが100%なら inode 枯渇です。原因はたいてい、一時ファイルやセッションファイルが大量に溜まっているディレクトリなので、不要な小ファイルを整理して解消します。
実務での使いどころ
ディスク関連の調査は、df → du → （必要なら）lsof の順が王道です。まず df -h で満杯の領域を特定し、du -h --max-depth=1 で原因ディレクトリを段階的に掘り、肥大化したファイルを突き止めて対処します。消したのに空きが戻らなければ lsof +L1 で削除済みファイルを掴むプロセスを探し、df -h で問題ないのに書けないなら df -i で inode を疑う——この分岐を覚えておけば、ディスク起因の障害はかなりの確率で自力で解決できます。日頃から df をたまに眺めて、満杯になる前に手を打つ習慣をつけておくと、そもそも障害として顕在化させずに済みます。