削除したファイルの容量が解放されない理由｜dfとduがズレる本当の原因

URLをコピーしました！

Linux運用で非常によくあるトラブルが、

「rmでファイルを削除したのに、ディスク容量が空かない」

という現象です。

この問題は、仕組みを理解していないと

無意味なrm -rfの連発
不要な再起動
原因不明のディスク逼迫

を引き起こします。

本記事では、なぜ削除しても容量が解放されないのかを Linuxの内部動作から実務対処まで一気通貫で解説します。

結論：ファイルは「削除」ではなく「参照解除」される

Linuxで rm を実行したとき、

実際に行われているのは「データの即時削除」ではありません。

正確には、

ディレクトリエントリ（ファイル名）を消す
inodeのリンク数を減らす

という処理です。

データ本体は、プロセスが掴んでいる限り残り続けます。

Linuxにおけるファイル削除の仕組み

Linuxのファイルは、以下の3要素で成り立っています。

ファイル名（ディレクトリエントリ）
inode（メタデータ）
データブロック（実体）

rm を実行すると、

ファイル名が消える
inodeのリンク数が0になる
しかしプロセスが開いていれば保持され続ける

その結果、

「見えないが存在するファイル」

が生まれます。

dfとduの結果が一致しない理由

duの特徴

du -sh /var/log

ファイル名が存在するものだけ集計
削除済みファイルは見えない

dfの特徴

df -h

ディスク上で確保されているブロックを集計
削除済みでも保持中ならカウントされる

この差が、

dfは満杯、duでは空いている

という現象を生みます。

典型的な発生シナリオ

巨大なログファイルを生成
rmで削除
アプリやサービスが再起動されていない

特に以下は頻発します。

Webサーバ（httpd / nginx）
アプリケーションログ
Javaプロセス

実務での確認方法（必須）

削除済みファイルを掴んでいるプロセス確認

lsof +L1

表示例：

java   12345 appuser  5w  REG  253,0  10G  1234567 /var/log/app.log (deleted)

この場合、

ファイルは削除済み
PID 12345 が掴み続けている
10GB分の容量が解放されない

なぜ再起動すると直るのか

プロセスを停止すると、

ファイルディスクリプタが閉じられる
inode参照が完全に消える
ディスクブロックが解放される

つまり、

「再起動＝掴んでいる手を離させる行為」

です。

正しい対処手順（再起動前）

lsof +L1 で該当プロセス特定
対象サービスを特定
サービス再起動

systemctl restart httpd

これで即座に容量が解放されます。

やってはいけない対処

原因不明のまま rm -rf
プロセスを理解せず kill -9
ディスクが空かないまま運用継続

根本原因は「削除方法」ではなく「プロセス管理」です。

logrotateとの関係（重要）

logrotateで

copytruncate

を使う理由は、

プロセスを止めずに
ファイルサイズだけを0にする

ためです。

ただし、これは応急処置であり、

本来は再起動・SIGHUP対応が理想

です。

まとめ

削除したのに容量が解放されない原因は、

Linuxの仕様通り、プロセスが正常に動いている証拠

でもあります。

重要なのは、

dfとduの役割を理解する
lsof +L1 を即叩く
プロセス単位で対処する

これだけで、ディスク逼迫トラブルの大半は解決できます。

ぜひ本記事を、「容量が空かない時の即確認チェックリスト」として活用してください。