我們先來模擬一下演示環境
首先我們看一下磁盤的存儲狀況
[root@Centos7 ~]#df? ? ?-h? ? ? ?#df? ?顯示每個文件所在的文件系統的信息 。-h以人類易讀的類型顯示。
文件系統? ? ? ? ? ? ? ?容量? ? ?已用? ?可用? ?已用%? 掛載點
[root@Centos7 ~]#dd if=/dev/zero of=/boot/456 bs=1M count=900
##dd if=/dev/zero of=/boot/456 bs=1M count=900? #通俗點來講及時批量創建文件內容到/boot/456中。
input? file? ? ? ?output? file? ? block size? ? ? ?count
輸入文件? ? ? ? ? 輸出文件 （批次大小） （批次）
[root@Centos7 ~]#ll? -h? /boot/456? ?顯示/boot/456的文件的詳細信息
#通過df -h命令我們看到 /boot目錄的使用率已經100%了。
下面我們通過常用的命令rm來進行刪除
刪除操作執行成功了，怎么/boot目錄的使用率還是100%？難道文件還存在？？
那我們通過#ll -h /boot來查看一下/boot下的文件列表。是不是很奇怪？文件沒有了為什么占用的空間卻沒有正常的釋放！難道系統出問題了？
那怎么辦呢？
不要擔心，接下來我們來排查一下問題。
因為命令執行沒有失敗，文件也確實刪除掉了。
那么我們來通過lsof命令：來查詢一下文件即被打開編輯中同時又被執行了刪除操作的文件。
[root@Centos7 ~]#lsof |grep deleted
通過查詢我們看到最下邊的那一條vi編輯著的文件居然就是我們剛剛刪除的/boot/456文件，占用的空間居然還是800+M大小。
這就是明明刪除了文件，可是存儲空間卻沒有及時釋放的原因了。因為文件還在使用中，系統默認是在程序關掉后才會釋放空間。我們直接kill殺掉這個進程既可以了。
其實工作中經常遇到這種情況，服務器是很多人都可以訪問的，部分文件（例如日志文件等）的訪問權限比較低大多數都是開放讀寫權限的。這就有可能造成一個人在刪除日志文件的同時，還有別的同事正打開查看這個日志文件。從而造成空間未及時釋放。
[root@Centos7 ~]#kill -9 PID? ? 【PID 即程序運行的ID編號，實驗中的編號是3699】
[root@Centos7 ~]#kill -9 3699
殺掉該進程后df -h 命令發現空間立刻釋放出來了，是不是很神奇呢！
接下來，我們再來介紹另外一種刪除釋放存儲空間的辦法。這種方法就不會出現rm刪除后可能無法及時釋放空間的問題。
首先：我們先來恢復一下上面的實驗環境，還是/boot 目錄吧
環境搭建好了。
接下來開始試驗
[root@Centos7 ~]#> /boot/456? ?#這里我們使用【>】來先清空文件內容。
清空后df -h發現存儲空間即刻得到釋放了。
當然如果文件真的不需要了，在執行rm命令刪除即可。
后邊介紹的這種方法，是不是又簡單又實用呢？
不過這兩種方法使用的時候要注意文件不要跟錯咯，否則刪除的文件都是很難恢復的哦！
小伙伴們還有沒有別的更好的方法呢？
本文來自投稿，不代表Linux運維部落立場，如若轉載，請注明出處：http://www.www58058.com/88533
