執行 df -h 顯示磁碟使用 5.2GB，但 du -sh /* 統計目錄總和僅 2.9GB，差異 2.3GB 去哪了？主因：檔案已被 rm 刪除，但相關進程仍持有開啟的檔案描述符 (file descriptor)，資料塊未真正釋放，類似「回收站」佔用空間。

現象重現與分析

1. df -h：根分區 Used 5456700 KB (≈5.2GB)。
2. du -sh /*：排除掛載點 (/proc, /sys 等)，目錄總和 3075332 KB (≈2.93GB)。
3. 差異 2.27GB 為「已刪除但進程持有」的幽靈檔案。

定位幽靈檔案：lsof + grep deleted

lsof | grep deleted

輸出範例：

node    1234 user  4u   REG  253,0  2300000  12 /var/log/app.log (deleted)

顯示：進程 PID 1234 (node) 持有已刪除的 /var/log/app.log，佔用 2.3GB。

釋放空間：重啟對應進程

1. 優雅重啟：systemctl restart 服務名 或發送 SIGHUP 讓進程重新開啟日誌檔。
2. 強制結束：kill -9 PID (若服務有 systemd 管理會自動重啟)。
3. 驗證：再次執行 df -h，Used 應下降至接近 du 統計值。

預防與最佳實務

• 日誌輪轉：配置 logrotate 定期切割/壓縮/清理舊日誌，避免單一檔案過大。
• 程式設計：寫入大量日誌時，定期 fsync 或使用 rotating file handler，避免長時間持有巨大檔案描述符。
• 監控告警：Prometheus + Node Exporter 監控 node_filesystem_avail_bytes 與 node_filesystem_free_bytes 差異，異常報警。

生產環境不可輕易重啟伺服器，lsof | grep deleted 定位並重啟持有進程是釋放幽靈檔案空間的標準作法。