問題說明：IDC里的一台服務器的/分區使用率爆滿了！已達到100%！經查看發現有個文件過大（80G），於是在跟有關同事確認后rm -f果斷刪除該文件。但是發現刪除該文件后，/分區的磁盤空間壓根沒有釋放出來，使用率還是100%！這是為什么呢？？
[root@linux-node1 ~]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
58G 7.8G 47G 100% /
tmpfs 1.9G 0 1.9G 0% /dev/shm
/dev/vda1 190M 72M 108M 40% /boot
原因分析：
在Linux系統中，通過rm或者文件管理器刪除文件，只是將它會從文件系統的目錄結構上解除鏈接(unlink)，也就是說只是刪除了文件和系統目錄結構的鏈接；如果文件在刪除時是被打開的（有一個進程正在使用該文件，文件被進程鎖定或者有進程一直在向這個文件寫數據等）狀態，那么進程將仍然可以讀取該文件，也就是說沒有刪除掉文件在讀取的狀態，所以磁盤空間也就會一直被占用。 [ 在另一篇文章：https://www.cnblogs.com/kevingrace/p/8076488.html 中(第"十一"部分)處也提到了這個問題 ]
一個文件在文件系統中的存放分為兩個部分：數據部分和指針部分，指針位於文件系統的meta-data中，數據被刪除后，這個指針就從meta-data中清除了，而數據部分存儲在磁盤中，數據對應的指針從meta-data中清除后，文件數據部分占用的空間就可以被覆蓋並寫入新的內容，之所以出現刪除文件后，空間還沒釋放，就是因為有進程還在一直向這個文件寫入內容，導致雖然刪除了文件，但文件對應的指針部分由於進程鎖定，並未從meta-data中清除，而由於指針並未被刪除，那么系統內核就認為文件並未被刪除，因此通過df命令查詢空間並未釋放也就不足為奇了。
解決措施有以下幾種：
1）通過lsof|grep deleted命令獲取到已經被刪除但是仍然被應用程序占用的文件列表，然后kill掉還在占用所刪除文件的進程。需要注意的是：如果有很多進程都在使用所刪除文件，那么采用第1種方式kill進程就有點麻煩了，而且風險也比較大。因為kill進程是通過截斷proc文件系統中的文件可以強制要求系統回收分配給正在使用的的文件。必須要確定不會對運行中的進程造成影響時才能使用，應用程序對這種方式支持的並不好，當一個正在使用的文件被截斷可能會引發不可預知的問題。
2）或停掉或重啟使用這個所刪除文件的應用，讓OS自動回收磁盤空間。
3）也可以重啟操作系統，不過這並不是最好的方法
4）對待這種進程不停對文件寫日志的操作，要釋放文件占用的磁盤空間，最好的方法是在線清空這個文件。通過這種方法，磁盤空間不但可以馬上釋放，也可保障進程繼續向文件寫入日志。
在線清空文件（比如/home/wangshibo.log）的方式：
a）# echo " " > /home/wangshibo.log b）# cat /dev/null > /home/wangshibo.log c）# > /home/wangshibo.log
還有一種磁盤空間使用問題的現象：明明使用df -h命令查看磁盤空間使用率不算高，還有很多空余空間，但是創建文件或寫入數據時一直報錯磁盤寫滿：" no space left on device"！這個參考：由索引節點(inode)爆滿引發的問題
一般這種問題都是由於分區目錄下deleted刪除后的資源空間沒有真正釋放出來導致的, 具體處理流程如下:
-> 先df -lh查看一下磁盤使用狀況, 發現/data分區下的Used已用空間很大, 但是實際查看並沒有占用那么大的空間!
-> 找到被刪除文件所在的分區, 比如/data分區
-> 查看被刪除了的所有文件：lsof -n /data |grep deleted
-> 殺死這些文件的delete進程, 釋放空間: lsof -n /data |grep deleted|awk '{print $2}'|xargs kill -9
-> 接着再運行lsof -n /data |grep delete，應該就沒有結果了。
-> 注意: 剛殺死deleted進程時, df -h查看/data 分區, Used已用空間可能時瞬間顯示過大, 但隨着deleted進程殺死, 資源逐漸釋放, /data分區下的Used已用空間會逐漸變小, Avail可用空間會逐漸變大)
大多數文件系統都會保留一部分空間留作緊急情況時用（比如硬盤空間滿了），這樣能保證有些關鍵應用（比如數據庫）在硬盤滿的時候有點余地，不致於馬上就 crash，給監控系統和管理員一點時間去察覺。不過有時候這部分預留的硬盤空間不用的話有點浪費。
在Linux系統中，ext2、ext3、ext4文件系統上通常會默認預留5％的磁盤空間，比如磁盤如果是2TB，這就意味着有100GB的空間會被預留下來，這樣的話會不會顯得有點浪費了。可以通過"tune2fs"命令來改變5％的默認設置，比如只預留2％的空間。但是不建議設成0%，現實環境中這樣做不安全。
[root@ss-server ~]# df -T Filesystem Type 1K-blocks Used Available Use% Mounted on /dev/vda1 ext4 41151808 4962148 34076228 13% / devtmpfs devtmpfs 1931468 0 1931468 0% /dev tmpfs tmpfs 1941204 0 1941204 0% /dev/shm tmpfs tmpfs 1941204 652 1940552 1% /run tmpfs tmpfs 1941204 0 1941204 0% /sys/fs/cgroup tmpfs tmpfs 388244 0 388244 0% /run/user/0 [root@ss-server ~]# df -h Filesystem Size Used Avail Use% Mounted on /dev/vda1 40G 4.8G 33G 13% / devtmpfs 1.9G 0 1.9G 0% /dev tmpfs 1.9G 0 1.9G 0% /dev/shm tmpfs 1.9G 620K 1.9G 1% /run tmpfs 1.9G 0 1.9G 0% /sys/fs/cgroup tmpfs 380M 0 380M 0% /run/user/0 比如上面"/"分區是ext4文件系統，默認系統預留了5%也就是2G的空間。 現在可以通過"tune2fs"命令將系統預留空間改為2%。 [root@ss-server ~]# tune2fs -m 2 /dev/vda1 tune2fs 1.42.9 (28-Dec-2013) Setting reserved blocks percentage to 2% (209704 blocks) 執行后，發現"/"分區騰出了1G的空間，這時系統預留空間也就是2%了。 [root@ss-server ~]# df -h Filesystem Size Used Avail Use% Mounted on /dev/vda1 40G 4.8G 34G 13% / devtmpfs 1.9G 0 1.9G 0% /dev tmpfs 1.9G 0 1.9G 0% /dev/shm tmpfs 1.9G 620K 1.9G 1% /run tmpfs 1.9G 0 1.9G 0% /sys/fs/cgroup tmpfs 380M 0 380M 0% /run/user/0 注意： Linux下只有ext2、ext3、ext4文件系統時，系統才會默認預留5%的磁盤空間。 如果文件系統是xfs、tmpfs、devtmpfs、overlay等，則系統默認不會預留磁盤空間。