NoteStack

This page is a beginner-friendly note about reading df -h output. It focuses on what to watch in real operations, not just column definitions.

「埋まりそうで焦る」df -h の見方とディスク容量の注視点

df -h の各行を「どこが本命か」「何を危険サインと見るか」の判断に落とし込んで整理します。

まず前提：df -h は「ディスク（ファイルシステム）の空き具合」を見る

最初に、df -h が何の話かだけ揃えます。

見ているもの
  • ファイルを保存する領域が、いまどれくらい埋まっているか
  • 「全体容量」「使用済み」「残り」「使用率」を、マウント先（どこに繋がっているか）ごとに一覧化
-h の意味

-h は Human readable（人が読みやすい単位）で、G や M のように表示してくれます。

よく混ざる注意

df -h は基本的に「ディスクの空き」ですが、出力には tmpfs のような メモリ上の一時領域も混ざります（後で区別します）。

列の意味：ここだけ読めれば “だいたい” 困らない

まずは列名の意味を、運用で使う言葉に置き換えます。

Filesystem（対象）

どの領域を見ているかです。例：/dev/vda2 のような実ディスク、tmpfs のような仮想領域。

Size（総容量）

その領域に用意されている全体サイズです。

Used（使用済み）

すでに使っている量です。

Avail（残り）

いま追加で使える空きです（ここが少ないと “書けない” が起こります）。

Use%（使用率）

埋まり具合の割合です。運用判断では、まずこれを見ます。

Mounted on（どこに繋がっているか）

この領域が、OSのどの場所（パス）として見えているかです。例：/（ルート）や /var など。

最初に見る場所：だいたいは Mounted on が / の行

初心者の頃は「行が多くてどれを見ればいいか」が一番迷います。

基本の判断
  • まず Mounted on が / の行を見る（ここが“本丸”になりやすい）
  • そこが余裕なら、次に /var や /home が別パーティションかどうかを見る
なぜ / が重要？

/ の中には、ログ（/var/log）、Web（/var/www）、設定（/etc）、ユーザー（/home）など、よく増えるものがまとまって入ることが多いからです。

読み方の例：/dev/vda2 ... / を “文章” にするとこうなる

出力をそのまま眺めると数字の羅列なので、1行を文章にして読み替えます。

例（よくある行）
/dev/vda2   25G   7.3G   17G   32%   /
意味（こう読めばOK）
  • / に繋がった実ディスク領域が 25GB ある
  • そのうち 7.3GB 使っている
  • 残りは 17GB ある
  • 使用率は 32% なので、現状は余裕がある
この行だけで分かる結論

いま “ディスクが埋まりそう” で困る状態ではありません（ただし、増え方が急だと別なので後で触れます）。

tmpfs / devtmpfs は “ディスク” じゃないことが多い

ここを誤解すると、判断がズレやすいです。

devtmpfs（例：/dev）

デバイスファイル（OSが使う入口）のための領域で、実ディスク逼迫の指標としては見ません。

tmpfs（例：/run / /dev/shm / /run/user/1000）
  • メモリ上の一時領域で、再起動すると消えるものが多いです
  • ここが空いていても、/ が埋まっていたらディスクとしては危険です
  • 逆に、ここが減っているのは「メモリ寄りの問題」につながることがあります（ディスク不足とは別軸）
混ざる理由

df は “ファイルシステムとして見えているもの” を全部並べるので、メモリ上のファイルシステムも表示されます。

注視する点：Use% の “目安” を決めておく

運用で困るのは「何%から危ないの？」が曖昧なまま放置してしまうことです。

ざっくり目安（迷ったらこれ）
  • 80%：原因調査を始める（“増え方” を見る）
  • 90%：かなり危険（削除・移動・拡張の準備）
  • 95%〜：事故が起きやすい（ログが書けない／更新失敗／DB書き込み失敗など）
なぜ空きが少ないと困る？
  • Nginx / systemd / アプリがログを書けずに動作が不安定になる
  • パッケージ更新（例：dnf）が途中で失敗する
  • 一時ファイルが作れず、ビルドや圧縮、証明書更新などが失敗する
  • DBやキューの書き込みが止まり、サービスとして致命傷になる

注意点：容量が余っていても “inode” が尽きると詰まる

「空きはあるのにファイルが作れない」系の事故は、ここが原因になりがちです。

inode って何？（やさしく）

ファイルを置くための “席（番号）” みたいなものです。小さなファイルを大量に作ると、容量より先に席が埋まることがあります。

確認コマンド
df -i

IUse% が高い場合は、ログの分割生成やキャッシュの増殖を疑います。

増えやすい犯人：/var/log とアプリ独自ログ

ディスクが急に埋まるときは、原因が “一部のディレクトリ” に偏っていることが多いです。

まずは「重い場所」を探す

ルート直下の “どれが太っているか” を見ます。

sudo du -xh --max-depth=1 / | sort -h
ログが怪しいとき

よくあるのは /var 配下（特にログ）です。

sudo du -xh --max-depth=1 /var | sort -h
sudo du -xh --max-depth=1 /var/log | sort -h
“削除していいか” の注意
  • ログを消す前に、まずは “何のログか” を特定します
  • 稼働中のプロセスがログを書き続けていると、削除しても解放されないケースがあります（運用としては慎重に）
  • 根本は「ローテーション（周期で切り替え）」と「上限（保持日数・サイズ）」です

よくある誤解：Avail だけ見て安心／不安になる

数字は大事ですが、判断のコツを決めておくと迷いが減ります。

おすすめの見方
  • Use% を主に見る（危険ラインが決めやすい）
  • Avail は「残り何GBか」感覚を掴むために併用する
  • 急増する環境（ログが多い等）なら、前回との差分を記録して “増え方” を見る
増え方を見る例

毎日1回だけでも、出力を残すと変化が分かります。

df -h
df -i

（運用としては、ログやメモに貼るだけでも十分役立ちます。）

ミニチェック：この結果を見たら、次に何を判断する？

「見る→判断する」を短いチェックに落とします。

チェック1：Mounted on が / の Use% は？

80%を超えていたら、場所の特定（du）に進みます。

チェック2：tmpfs を “ディスク” と勘違いしていない？

tmpfs が減っているのは、基本的にメモリ上の話なので、ディスク逼迫の判断とは切り分けます。

チェック3：小さいファイルが大量に増えていない？

df -i で inode を確認します（容量が余っていても詰まるパターンを潰します）。

よくある質問（FAQ）

Q. どの行が “本物のディスク” ですか？

A. まずは Mounted on が / の行を見ます。Filesystem が /dev/... のように始まるものは実ディスクであることが多く、tmpfs はメモリ上の一時領域です。

Q. tmpfs の Use% が増えているのは危険ですか？

A. “ディスク不足” とは別の意味です。tmpfs はメモリ上なので、増え方が異常ならメモリ圧迫やプロセス挙動の確認につながりますが、まずディスク容量の危険度は / の Use% で判断します。

Q. Use% が 80% を超えたら、まず何をすればいいですか？

A. いきなり削除せず、du で “どこが太っているか” を特定します。特に /var と /var/log が増えていないかを見るのが定番です。

Q. 容量は空いているのにファイルが作れません。

A. inode が尽きている可能性があります。df -i を実行して、IUse% が高くないか確認します。