前言

某天更新服務(wù)時(shí)，發(fā)現(xiàn)服務(wù)怎么也上傳不了，原因是磁盤空間不足，這很簡(jiǎn)單，直接找到大文件刪除rm -rf 即可，但是我刪除之后，df -h 發(fā)現(xiàn)磁盤空間一點(diǎn)變化都沒(méi)有，可用率還是滿的

排查

隨后進(jìn)行問(wèn)題排查

難道是系統(tǒng)反應(yīng)慢，沒(méi)有刷新造成的？

我就立即執(zhí)行

lecho 3 > /proc/sys/vm/drop_caches

這個(gè)命令會(huì)強(qiáng)制釋放系統(tǒng)緩存空間，清空所有級(jí)別的緩存，包括頁(yè)面緩存、dentry緩存和inode緩存

但是沒(méi)什么用。。。。。

于是百度了示意

在 Linux 中，文件存儲(chǔ)在硬盤上的最小存儲(chǔ)單位是扇區(qū)（Sector），每個(gè) sector 只有 512字節(jié)大小；多個(gè) sector 可以組成文件塊 （block） 。當(dāng)我們讀取某個(gè)文件數(shù)據(jù)的時(shí)候，操作系統(tǒng)就需要知道這個(gè)文件存儲(chǔ)在哪個(gè) block 上。文件的數(shù)據(jù)存放位置信息被存放到了 inode （索引節(jié)點(diǎn)）上。也就是說(shuō)，在 Linux 下，文件由指針部分（inode）和數(shù)據(jù)部分（data）組成。

因此，執(zhí)行 rm xxx 命令刪除文件的時(shí)候，只是刪掉了inode數(shù)據(jù)，而文件的實(shí)際數(shù)據(jù)部分在 inode 被清除掉之后，會(huì)被覆蓋并寫入新的內(nèi)容。但是如果文件在刪除的時(shí)候是被打開(kāi)的（有一個(gè)進(jìn)程正在使用該文件，文件被進(jìn)程鎖定或者有進(jìn)程一直在向這個(gè)文件寫數(shù)據(jù)等）狀態(tài)，那么進(jìn)程依舊可以讀取該文件，系統(tǒng)就會(huì)認(rèn)為該文件的磁盤空間一直被占用。

雖然刪除了文件，但是由于進(jìn)程還在一直向這個(gè)文件寫入內(nèi)容，文件的 inode 并沒(méi)有清除掉，系統(tǒng)內(nèi)核認(rèn)為文件并未刪除，這才出現(xiàn)空間不釋放的情況。也就是說(shuō)：當(dāng)一個(gè)進(jìn)程持續(xù)的寫入一個(gè)文件的時(shí)候，直接刪除這個(gè)文件，磁盤空間并不會(huì)得到釋放。

那么我們就清楚了，是被占用導(dǎo)致表象刪除，所以我們可以重啟相關(guān)服務(wù)，或者是直接殺死該進(jìn)程

解決

lsof | grep deleted | grep docker

我是docker相關(guān)服務(wù)引發(fā)的，所以我檢索了docker，各位在不清楚的時(shí)候可以不用檢索，直接lsof | grep deleted

于是我將這個(gè)進(jìn)程kill -9 進(jìn)程號(hào)

df- h

這樣就正常了

總結(jié)

以上為個(gè)人經(jīng)驗(yàn)，希望能給大家一個(gè)參考，也希望大家多多支持腳本之家。