作者 | 一得的跋涉
出品 | CSDN博客
對於 Linux 磁盤滿的問題，我們通常的處理思路是用 du 查找可清理的大文件，然後臨時刪掉讓磁盤使用率先降下來，從而儘快保證磁盤能繼續寫入。
但是，有一些情況的處理效果不太一樣，du/df 呈現的結果可能還會讓人迷惑不解。下面，我就分享下幾個工作中遇到過的較離奇的磁盤滿問題。
被忽略的隱藏文件
1、認識 swapfile
Linux 的交換文件 swapfile 的產生場景較普遍，而且也是以隱藏文件的形式存在的，因此這裡主要聊聊 swapfile 這一類的隱藏文件。
當用 vim 打開一個文件時，都會產生一個 .swp 的臨時隱藏交換文件，用來備份緩衝區中的內容。
當文件非正常關閉（比如直接關閉終端或者電腦斷電等）時，.swp文件不會被刪除，這樣就可以用此文件來恢復文件。（注意當正常關閉時，此文件會被刪除；且如果只是讀取文件，不會產生 .swp 文件）
而且，如果 vim 意外退出後，又重新打開文件二次編輯，那麼舊的 .swp 文件會繼續保留，併產生新的 .swo 臨時隱藏文件。
如果二次編輯的時候，vim 又異常退出了，那麼還會繼續產生新的臨時隱藏文件.swn、.swm、 .swl ……
2、處理建議
有些隱藏文件的磁盤佔用也挺大：
:/tmp # ll -rth | grep G
total 17.7G
-rw------- 1 xxxx users 17.6G 2020-02-12 18:27 .sqlkfJTFl.swp
所以有時候碰到大隱藏文件導致磁盤滿的情況，如果沒能發現這些隱藏文件，就會覺得離奇和疑惑。
所以在排查磁盤滿問題的時候，可以通過執行 vim -r 來查看和檢查下所有臨時交換文件的大小；或者通過 ls -lha 把所有隱藏文件都列出來看看大小。
如果不想留 swapfile 這個特性，可以考慮關掉 swapfile ：
vim /etc/vimrc
# 添加如下配置
set noswapfile # 禁止在編輯時候產生此文件；
但是注意這僅限於對文件損失可以容忍的情況下；如果不能容忍文件損失，那還是建議還是打開 swapfile：
vim /etc/vimrc
# 添加如下配置
set swapfile # 則是在編輯時候產生此文件；
未釋放的已刪除文件
1、du 和 df 不一致
如果隱藏文件因素排除了，還是發現 du 出來的大小詭異，比如 du 發現磁盤並沒有用滿，但是 df 看到磁盤使用率卻是 100% 。
這又會是什麼原因呢？
這時候，通常就得懷疑有一些已刪除的文件，還被一些進程 hold 住句柄沒釋放，導致這些文件雖然已經刪除，也的確看不到了，但是卻還佔著磁盤空間；
從而導致 du 和 df 出來的磁盤使用結果不一致的情況。
2、處理建議
通過執行 lsof | grep deleted 可以找到那些沒有釋放磁盤空間的文件和進程，
然後通過重啟對應進程，就可以達到釋放已刪除文件佔用的空間的目的。
這個帖子 《 清空熱文件的常見錯誤操作 》 闡述了 “已刪除文件還佔用磁盤” 的產生場景和處理方式。
另外，對於這種情況，還有個錯誤的處理方法，這裡特別提醒下：
有些同學在找到未釋放已刪除文件的 pid 之後，可能會直接通過 kill pid 來達到釋放已刪除文件的目的。
這種做法確實能夠釋放已刪除文件，從而釋放磁盤空間，但是這種做法是有副作用的，危害可大可小。
如果在離線環境這麼操作，影響一般不大；但是如果在生產環境這麼操作的話，那就可能搞出故障來了。
我們假設這麼一種場景：
生產環境的某程序由於某種Bug，一直不會釋放日誌文件，而分時寫入的日誌文件又是有過期刪除機制的，這樣一直持續下去，就會發現服務器上有大量的已過期刪除日誌文件還佔用著磁盤空間，直到產生磁盤滿風險。
那麼這個時候如果直接通過 kill pid 來處理的話，就直接把生產環境的在線程序直接幹掉了；這個後果就可想而知了：在這個程序被守護進程拉起來之前，這個服務都是不可用的。
掛載引發的懸案
1、消失的空間
如果執行 ls -lha 並沒有發現大隱藏文件，執行 lsof | grep deleted 也沒有發現未釋放的已刪除文件；但是 df 看到根目錄確實達到 100% 了 ，而 du 出來的根目錄實際使用空間卻並沒有用滿 。
這又會是什麼原因呢？
出現這種情況的時候，請回憶下最近這臺磁盤異常的機器，是否檢修 或者 換過磁盤？
根目錄出現這種離奇現象，通常就是在檢修/更換磁盤的時候（這裡假設是更換/data1 ）,新磁盤還沒掛載就開始往 /data1 寫數據了，這時候由於還沒掛載新盤，所以寫入數據佔用的是根目錄的空間。
然後換好/data1 盤並重新掛載上去後，原本放在 /data1 的數據，也不會出現在掛載盤上，還是繼續佔用根目錄的空間。
所以這時候就會出現這樣的現象：
掛載後 du /data1 並不大 ，但是掛載前 /data1目錄寫入的數據實際卻佔用了根目錄空間；而且這個數據在掛載後是看不到的，因此很難發現。於是就會發現根目錄有一些空間似乎憑空消失了，相當詭異。
2、處理建議
2.1 解決方法
怎麼確認是新的掛載盤掩蓋了一些數據呢？把新的掛載盤 /data1 umount掉，然後再看看 /data1 佔用的空間就知道了。
如果 umount提示 busy，可以通過執行以下命令來解決：
fuser -kmvi /data1 && umount /data1
卸載後，就會發現 /data1 目錄下確實有大量文件，刪除後，再 mount -a 重新掛載，然後根目錄消失的磁盤空間，一般就能找回來了。
2.2 測試驗證
如果還不放心的話，清理完數據再次掛載後，可以簡單測試下：
dd if=/dev/zero of=/data1 bs=1M count=20000
往 /data1 大概寫個 20G 數據，再觀察下根目錄的空間是否受影響，如果不受影響就說明問題解決！
2.3 給個建議
針對根目錄這類離奇問題：建議在每次更換磁盤重新做掛載動作之前，檢查一下根目錄的空間使用情況；如果存在錯誤寫入數據的情況，需要及時清理，然後再進行新盤掛載，切記。
原文鏈接：
https://blog.csdn.net/weixin_44648216/article/details/104505890
閱讀更多 CSDN 的文章
