1、錯誤現象
運維的監控系統發來通知，報告一台伺服器空間滿了，登陸伺服器檢視，根分割槽確實沒有空間了，如下圖所示：
這裡首先說明一下伺服器的一些刪除策略，由於linux沒有**站功能，我們的線上伺服器所有要刪除的檔案都會首先移動到系統/tmp目錄下，然後定期清除/tmp目錄下的資料。這個策略本身沒有問題，但是通過檢查發現這台伺服器的系統分割槽中並沒有單獨劃分/tmp分割槽，這樣/tmp下的資料其實是占用了根分割槽的空間。既然找到了問題，那麼刪除/tmp目錄下一些大資料即可，執行如下命令，檢查/tmp下最大的三個資料檔案，如下圖所示：
1
2
3
4
[root@localhost~ ]# du -s /tmp/*|sort -nr|head -3
69206016/tmp/access_log
36/tmp/hsperfdata_root
36/tmp/hsperfdata_mapred
通過命令輸出發現在/tmp目錄下有個66g大小的檔案access_log，這個檔案應該是apache產生的訪問日誌檔案，從日誌大小來看，應該是很久沒有清理apache日誌檔案了，基本判定是這個檔案導致的根空間爆滿，在確認此檔案可以刪除後，執行如下刪除操作：
[root@localhost ~]# rm /tmp/access_log
接著檢視系統根分割槽空間是否釋放，如下圖所示：
從輸出可以看到，根分割槽空間仍然沒有釋放，這是怎麼回事？
2、解決思路
一般說來不會出現刪除檔案後空間不釋放的情況，但是也存在例外，比如檔案被程序鎖定，或者有程序一直在向這個檔案寫資料等等，要理解這個問題，就需要知道linux下檔案的儲存機制和儲存結構。
3、問題排查
既然有了解決問題的思路，那麼接下來看看是否有程序一直在向acess.log檔案中寫資料，這裡需要用到linux下的lsof命令，通過這個命令可以獲取乙個已經被刪除但仍然被應用程式占用的檔案列表，命令執行如下圖所示：
從輸出結果可以看到，/tmp/acess.log檔案被程序httpd鎖定，而httpd程序還一直向這個檔案寫入日誌資料，從第七列可知，這個日誌檔案大小僅70g，而系統根分割槽總大小才100g，由此可知，這個檔案就是導致系統根分割槽空間耗盡的罪魁禍首，在最後一列的「deleted」狀態，說明這個日誌檔案已經被刪除，但由於程序還在一直向此檔案寫入資料，空間並未釋放。
4、解決問題
[root@localhost ~]# echo " " >/tmp/acess.log
運維實戰案例之檔案已刪除但空間不釋放問題解析
1 錯誤現象 運維的監控系統發來通知，報告一台伺服器空間滿了，登陸伺服器檢視，根分割槽確實沒有空間了，如下圖所示 這裡首先說明一下伺服器的一些刪除策略，由於linux沒有 站功能，我們的線上伺服器所有要刪除的檔案都會首先移動到系統 tmp目錄下，然後定期清除 tmp目錄下的資料。這個策略本身沒有問題...
運維技巧（9） 刪除和恢復已刪除的郵箱
恢復的郵箱已經不再是之前原使用者郵箱。因為在刪除郵箱時，原有ad使用者已經被刪除，即使新建同名使用者再將之前的郵箱恢復給新使用者，那也是不同的使用者。最佳實踐 建議使用禁用郵箱的功能。能否恢復已經刪除掉的郵箱，取決於組織對已刪除郵箱的保留期的設定，預設是30天。被刪除郵箱的特點 1 斷開使用者郵箱 ...
Linux 檔案已刪除但空間不釋放問題
有時候linux磁碟空間已滿，手動刪除了大檔案之後，df檢視一下發現空間占用還是100 這是啥問題呢?lsof grep deleted使用以上命令可以檢視已經刪除的檔案程序，kill掉之後，空間就能得到釋放。服務用不了，mysql插入資料超時堵塞，登入上伺服器檢視果然又是磁碟滿了，之前遇到過幾次這...