Linux 磁盤空間神秘消失？排查被刪除文件仍被進程佔用的實戰案例

詭異現場

# df -h
Filesystem           Size  Used Avail Use% Mounted on
/dev/cciss/c0d0p4    104G   42G   56G  43% /data

# du -sh /data/*
4.0K  ./corefile
4.0K  ./iostat.tmp
...
2.2G  ./web
# 明明只有 2.2G，df 卻顯示 42G，差 40G 去哪了？

兇手鎖定：已刪除文件的「幽靈句柄」

執行 lsof | grep delete 瞬間揭曉：

ttserver 30316 REG 104,4 2946659     7979020 /data/ttserver/bin/ttserver (deleted)
ttserver 30316 REG 104,4   70393     8028168 /data/tt_feeds/log/tt.log (deleted)
ttserver 30316 REG 104,4 42446163552 8028170 /data/pet50/ttserver/tt_feeds/data/tt_feeds.tch (deleted)

核心原因：`ttserver` 進程仍在運行，但其依賴的文件被手動刪除。Linux 允許進程繼續持有已刪除文件的打開句柄，數據繼續寫入磁盤塊，空間不釋放，`du` 看不見（目錄項已無），`df` 卻計入已用空間。

解決方案

1. 優雅重啟進程（推薦）：`systemctl restart ttserver` 或發送 `SIGTERM` 讓進程釋放句柄並重新打開新文件。
2. 強制殺進程：`kill -9 30316`，空間即時回收，但可能導致數據不一致。
3. 不重啟釋放空間技巧（高風險，慎用）：

   # 進入 /proc/30316/fd 找到對應文件描述符 (如 15)
   # 將其重定向到 /dev/null 或截斷
   : > /proc/30316/fd/15
   

預防最佳實踐

• 日誌輪轉用 `logrotate`，配合 `postrotate` 腳本發送 `SIGUSR1` 讓應用重新打開日誌，而非直接 `rm`。
• 部署文件監控告警：`lsof +L1` 定期掃描 `NLINK=0`（鏈接數為 0 即已刪除）的打開文件，超過閾值報警。
• 運維規範：刪除大文件前必須 `lsof | grep 文件名` 確認無進程持有，或先停止服務再清理。

結語

`df` 大、`du` 小，九成九是已刪除文件被進程持有。記住組合拳：lsof | grep delete 定位 → `kill -TERM PID` 釋放 → 修正運維流程防復發。不要讓「幽靈句柄」吞噬你的磁盤空間。