この記事について
この記事は、生成AIを活用した自動生成フローで作成しています。GNU Coreutilsのdf/du仕様を確認し、容量不足時に削除から始めず「何を測っている数字か」を分ける手順へ整理しました。Ubuntu実機での再実行は行っていません。検証ステータス：📘 GNU公式仕様確認済み・Ubuntu実機未確認
情報確認日：2026年10月2日。
dfとduはどちらもディスク容量を見るコマンドですが、同じ対象を同じ方法で数えているわけではありません。
まず読み取り専用で見る
TARGET="\${1:-$HOME}"
df -h "$TARGET"
du -sh "$TARGET"
dfはファイルシステム側の使用量を見る入口です。duは指定ディレクトリ以下を辿り、見つけたファイルの使用量を集計します。
数字が違う理由を分ける
dfはファイルシステム全体を見る
duは指定パス以下だけを見る
duが権限上たどれない場所がある
別マウントを含むかどうかが違う
削除済みでもプロセスが開いたままのファイルなど、名前から辿る集計だけでは見えにくい場合がある
1か所変える
TARGET="$HOME/Downloads" df -h "$TARGET" du -sh "$TARGET"
dfの対象ファイルシステムは同じでも、duの集計範囲が小さくなることを観察します。
flowchart TD A["容量が合わない"] --> B["df: filesystem"] A --> C["du: path走査"] B --> D["対象mount"] C --> E["範囲/権限"] D --> F["差を切り分け"] E --> F
仕事で使うなら
容量逼迫時にいきなり削除せず、dfで対象ファイルシステムを特定し、duで範囲を狭めます。
「同じディスクなのに違う数字」の見方
dfとduの差は、どちらかが間違っているとは限りません。dfはfilesystem側から使用状況を見ますが、duはdirectory treeを辿って見つけたfileを積み上げます。つまり観測地点が違います。
特に障害調査では「削除したのにdfが戻らない」という現象があります。プロセスが削除済みfileをopenしたままなら、directory名からは見えにくくても領域がまだ解放されていない場合があります。この記事の最小実験ではそこを再現しませんが、df/du差が残ったときの次の調査候補になります。
またduの対象pathとdfが示すmount pointを混同しないことも重要です。まずfilesystemを特定し、その後directory単位へ狭める順番にすると、慌てて大きなfileを削除する事故を減らせます。
