今天晚上收到一封服務器報警郵件的短信提醒，提示樓主所在公司的一臺備份服務器的磁盤剩餘空間不足20%，作爲24小時電話值班的樓主，趕緊打開筆記本，遠程登錄這臺服務器。然後，樓主頓時顫抖：
請看截圖（下面一個截圖爲樓上對服務器的該掛載點上的數據進行了些比較大清理操作）：
淡定的樓主此時沒法淡定，趕緊google、度娘：根據網上的大蝦們的的指點，原來df跟du的算法不一樣：
df命令 通過查看文件系統磁盤塊分配圖得出總塊數與剩餘塊數。
du -sh命令 通過將指定文件系統中所有的目錄、符號鏈接和文件使用的塊數累加得到該文件系統使用的總塊數。文件系統分配其中的一些磁盤塊用來記錄它自身的一些數據，如i節點，磁盤分佈圖，間接塊，超級塊等。這些數據對大多數用戶級的程序來說是不可見的，通常稱爲Meta Data。du命令是用戶級的程序，它不考慮Meta Data，而df命令則查看文件系統的磁盤分配圖並考慮Meta Data。因此正常情況下，df計算的USED空間會比du計算的結果要稍大。
同時，大仙們對上面截圖出現的問題的見解是，某個或者某些進程在沒有釋放掉刪除了的文件而導致。頓時樓主感覺茅塞頓開，原諒樓主的草率：
樓主馬上進行如下操作：
1.fuser -mv /web 去查看那些進程使用該目錄下的文件。
2.將使用該目錄下的大的進程做記錄，並將這些進程一個個的kill掉，kill掉過程中使用df -h 進行觀察:
3.終於ok，如下截圖，原來是nginx進程惹的禍：
總結，處理該問題過於草率，如果爲線上服務器這樣操作會對線上的服務有多大影響不可估量，而且時間的把控上面也未知。處理完成該問題後，樓主發現有蝦米這樣處理該問題:查看deleted文件使用的進程，然後將這些kill掉，losf |grep deleted ，然後kill掉這些pid。待樓主以後驗證。