1．錯誤現象
這個案例很有意思，就記錄了下來，運維的監控系統發來通知，報告一台伺服器空間滿了，登入伺服器檢視，根分區确實沒有空間了，如下圖所示。
這裡首先說明一下伺服器的一些删除政策，由于Linux沒有資源回收筒功能，我們将線上伺服器上所有要删除的檔案都會先移動到系統/tmp目錄下，然後定期清除/tmp目錄下的資料。這個政策本身沒有問題，但是通過檢查發現這台伺服器的系統分區中并沒有單獨劃分/tmp分區，這樣/tmp下的資料其實占用了根分區的空間。既然找到了問題，那麼删除/tmp目錄下一些大資料即可，檢查/tmp下最大的三個資料檔案，如下圖所示。
通過指令輸出發現在/tmp目錄下有個66GB大小的檔案access_log，這個檔案應該是apache産生的通路日志檔案，從日志大小來看，應該是很久沒有清理apache日志檔案了，基本判定是這個檔案導緻的根空間爆滿，在确認此檔案可以删除後，執行如下删除操作：
[root@localhost ~]# rm /tmp/access_log 接着檢視系統根分區空間是否釋放，如下圖所示。
從輸出可以看到，根分區空間仍然沒有釋放，這是怎麼回事？
2．解決思路
一般說來不會出現删除檔案後空間不釋放的情況，但是也存在例外，比如檔案被程序鎖定，或者有程序一直在向這個檔案寫資料等，要了解這個問題，就需要知道Linux下檔案的存儲機制和存儲結構。
一個檔案在檔案系統中的存放分為兩個部分：資料部分和指針部分，指針位于檔案系統的meta-data中，在将資料删除後，這個指針就從meta-data中清除了，而資料部分存儲在磁盤中。在将資料對應的指針從meta-data中清除後，檔案資料部分占用的空間就可以被覆寫并寫入新的内容，之是以在出現删除access_log檔案後，空間還沒釋放，就是因為httpd程序還在一直向這個檔案寫入内容，導緻雖然删除了access_log檔案，但是由于程序鎖定，檔案對應的指針部分并未從meta-data中清除，而由于指針并未被删除，系統核心就認為檔案并未被删除，是以通過df指令查詢空間并未釋放也就不足為奇了。
3．問題排查
既然有了解決問題的思路，那麼接下來看看是否有程序一直在向access_log檔案中寫資料，這裡需要用到Linux下的lsof指令，通過這個指令可以擷取一個已經被删除但仍然被應用程式占用的檔案清單，指令執行如下圖所示。
從輸出結果可以看到，/tmp/acess.log檔案被程序httpd鎖定，而httpd程序還一直向這個檔案寫入日志資料。從第七列可知，這個日志檔案大小僅70GB，而系統根分區總大小才100GB，由此可知，這個檔案就是導緻系統根分區空間耗盡的罪魁禍首。最後一列的“deleted”狀态說明這個日志檔案已經被删除，但由于程序還在一直向此檔案寫入資料，空間并未釋放。
4．解決問題
到這裡問題就基本排查清楚了，解決這一類問題的方法有很多種，最簡單的方法是關閉或重新開機httpd程序，當然也可以重新開機作業系統，不過這并不是最好的方法。對待這種程序不停對檔案寫日志的操作，要釋放檔案占用的磁盤空間，最好的方法是線上清空這個檔案，具體可以通過如下指令完成：
[root@localhost ~]# echo " " >/tmp/access_log 通過這種方法，磁盤空間不但可以馬上釋放，也可保障程序繼續向檔案寫入日志，這種方法經常用于線上清理Apache、Tomcat、Nginx等Web服務産生的日志檔案。