linux中如何解決檔案已刪除但空間不釋放的案例

一般來說不會出現刪除檔案後空間不釋放的情況，但是也存在例外，比如檔案被程式鎖定，或者有程式一直在向這個檔案寫資料等，要理解這個問題，就需要知道 下檔案的儲存機制和儲存結構。

運維的監控系統發來通知，報告一臺伺服器空間滿了，登入伺服器檢視，根分割槽確實沒有空間了：

[root@localhost ~]# df -h

這裡首先說明一下伺服器的一些刪除策略，由於Linux沒有回收站功能，所以線上伺服器上所有要刪除的檔案都會先移動到系統/tmp目錄下，然後定期清除/tmp目錄下的資料。這個策略本身沒有問題，但是透過檢查發現這臺伺服器的系統分割槽中並沒有單獨劃分/tmp分割槽，這樣/tmp下的資料其實佔用了根分割槽的空間。既然找到了問題，那麼刪除/tmp目錄下一些佔空間較大的資料檔案即可，檢查/tmp下最大的三個資料檔案。

[root@localhost ~]# du -sh /tmp/*|sort -nr|head -3

透過 輸出發現在/tmp目錄下有個66GB大小的檔案access_log，這個檔案應該是Apache產生的訪問日誌檔案，從日誌大小來看，應該是很久沒有清理Apache日誌檔案了，基本判定是這個檔案導致的根空間爆滿，在確認此檔案可以刪除後，執行如下刪除操作：

[root@localhost ~]# rm /tmp/access_log

接著檢視系統根分割槽空間是否釋放:

[root@localhost ~]# df -h

從輸出可以看到，根分割槽空間仍然沒有釋放，這是怎麼回事?

一般來說不會出現刪除檔案後空間不釋放的情況，但是也存在例外，比如檔案被程式鎖定，或者有程式一直在向這個檔案寫資料等，要理解這個問題，就需要知道Linux下檔案的儲存機制和儲存結構。

一個檔案在檔案系統中的存放分為兩個部分：資料部分和指標部分，指標位於檔案系統的meta-data中，在將資料刪除後，這個指標就從meta-data中清除了，而資料部分儲存在磁碟中。在將資料對應的指標從meta-data中清除後，檔案資料部分佔用的空間就可以被覆蓋並寫入新的內容，之所以在出現刪除access_log檔案後，空間還沒釋放，就是因為httpd程式還在一直向這個檔案寫入內容，導致雖然刪除了access_log檔案，但是由於程式鎖定，檔案對應的指標部分並未從meta-data中清除，而由於指標並未刪除，系統核心就認為檔案並未刪除，因此透過df 查詢空間並未釋放也就不足為奇了。

既然有了解決問題的思路，那麼接下來看看是否有程式一直在向access_log檔案中寫資料，這裡需要用到Linux下的lsof命令，透過這個命令可以獲取一個仍然被應用程式佔用的已刪除檔案列表，命令執行如下：

[root@localhost ~]# lsof | grep delete

從輸出結果可以看到，/tmp/access_log檔案被程式httpd鎖定，而httpd程式還一直向這個檔案寫入日誌資料。從第7列可知，這個日誌檔案大小約70GB，而系統根分割槽總大小才100GB，由此可知，這個檔案就是導致系統根分割槽空間耗盡的罪魁禍首。最後一列的“deleted”狀態說明這個日誌檔案已經被刪除，但由於程式還在一直向此檔案寫入資料，因此空間並未釋放。

到這裡問題就基本排查清楚了，解決這一類問題的方法有很多種，最簡單的方法是關閉或重啟httpd程式，當然也可以重啟作業系統，不過這些並不是最好的方法。對待這種程式不停對檔案寫日誌的操作，要釋放檔案佔用的磁碟空間，最好的方法是線上清空這個檔案，具體可以透過如下命令完成：

[root@localhost ~]# echo " " >/tmp/acess.log

透過這種方法，磁碟空間不但可以馬上釋放，也可保障程式繼續向檔案寫入日誌，這種方法經常用於線上清理Apache、Tomcat、Nginx等Web服務產生的日誌檔案。

原文地址：