在我的生活當中遇到磁盤快滿了，這時候準備去删除一些大檔案
于是我使用ncdu 檢視了一下目前系統占用資源比較多的是那些檔案，結果一看是elasticsearch的日志檔案，好吧，竟然找到源頭了，那就把它給删除了吧，
來到相應的路徑下之後，然後粗暴一點，執行 rm -rf *
很高興，終于把這些占用系統資源的壞東西給殺死了。滿心歡喜的去檢視磁盤情況。
給我當頭一棒，磁盤并沒有多大的變化，之後釋放了100多M，但是我明明删除了30G的檔案啊，這是怎麼回事。
有問題不可怕，幹淨找baidu/google，找到原因了，說是雖然删除了，但是沒有釋放資源。
從網上找了一些資料：
執行 lsof | grep deleted我發現有大量剛剛删除檔案的程序存在，果斷給他kill 掉。但是可能會造成一些影響，比如說一下正在寫的檔案，之前那樣删除的方法就是不對的。
下面是我從網上找的一下資料：
轉載于：http://ixdba.blog.51cto.com/2895551/1435781
1、錯誤現象
運維的監控系統發來通知，報告一台伺服器空間滿了，登陸伺服器檢視，根分區确實沒有空間了，如下圖所示：
這 裡首先說明一下伺服器的一些删除政策，由于Linux沒有資源回收筒功能，我們的線上伺服器所有要删除的檔案都會首先移動到系統/tmp目錄下，然後定期清除 /tmp目錄下的資料。這個政策本身沒有問題，但是通過檢查發現這台伺服器的系統分區中并沒有單獨劃分/tmp分區，這樣/tmp下的資料其實是占用了根 分區的空間。既然找到了問題，那麼删除/tmp目錄下一些大資料即可，執行如下指令，檢查/tmp下最大的三個資料檔案，如下圖所示：
| 1 2 3 4 | |
通過指令輸出發現在/tmp目錄下有個66G大小的檔案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、問題排查
既然有了解決問題的思路，那麼接下來看看是否有程序一直在向acess.log檔案中寫資料，這裡需要用到Linux下的lsof指令，通過這個指令可以擷取一個已經被删除但仍然被應用程式占用的檔案清單，指令執行如下圖所示：
從 輸出結果可以看到，/tmp/acess.log檔案被程序httpd鎖定，而httpd程序還一直向這個檔案寫入日志資料，從第七列可知，這個日志檔案 大小僅70G，而系統根分區總大小才100G，由此可知，這個檔案就是導緻系統根分區空間耗盡的罪魁禍首，在最後一列的“deleted”狀态，說明這個 日志檔案已經被删除，但由于程序還在一直向此檔案寫入資料，空間并未釋放。
4、解決問題
到 這裡問題就基本排查清楚了，解決這一類問題的方法有很多種，最簡單的方法是關閉或者重新開機httpd程序，當然也可以重新開機作業系統，不過這并不是最好的方 法，對待這種程序不停對檔案寫日志的操作，要釋放檔案占用的磁盤空間，最好的方法是線上清空這個檔案，可以通過如下指令完成：
[root@localhost ~]# echo " " >/tmp/acess.log
通過這種方法，磁盤空間不但可以馬上釋放，也可保障程序繼續向檔案寫入日志，這種方法經常用于線上清理Apache、Tomcat、Nginx等Web服務産生的日志檔案。