作者 | 一得的跋涉
責編 | 伍杏玲
出品 | 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 ***x users 17.6g 2020-02-12 18:27 .sqlkfjtfl.swp
所以在排查磁碟滿問題的時候，可以通過執行 vim -r 來檢視和檢查下所有臨時交換檔案的大小；或者通過 ls -lha 把所有隱藏檔案都列出來看看大小。
如果不想留 swapfile 這個特性，可以考慮關掉 swapfile ：
vim /etc/vimrc
# 新增如下配置
set noswapfile # 禁止在編輯時候產生此檔案；
vim /etc/vimrc # 新增如下配置set swapfile # 則是在編輯時候產生此檔案；如果隱藏檔案因素排除了，還是發現 du 出來的大小詭異，比如 du 發現磁碟並沒有用滿，但是 df 看到磁碟使用率卻是 100% 。
這又會是什麼原因呢？
這時候，通常就得懷疑有一些已刪除的檔案，還被一些程序 hold 住控制代碼沒釋放，導致這些檔案雖然已經刪除，也的確看不到了，但是卻還佔著磁碟空間；
從而導致 du 和 df 出來的磁碟使用結果不一致的情況。
2、處理建議
通過執行 lsof | grep deleted 可以找到那些沒有釋放磁碟空間的檔案和程序，
然後通過重啟對應程序，就可以達到釋放已刪除檔案占用的空間的目的。
這個帖子 《 清空熱檔案的常見錯誤操作 》 闡述了 「已刪除檔案還占用磁碟」 的產生場景和處理方式。
有些同學在找到未釋放已刪除檔案的 pid 之後，可能會直接通過 kill pid 來達到釋放已刪除檔案的目的。
這種做法確實能夠釋放已刪除檔案，從而釋放磁碟空間，但是這種做法是有***的，危害可大可小。
如果在離線環境這麼操作，影響一般不大；但是如果在生產環境這麼操作的話，那就可能搞出故障來了。
我們假設這麼一種場景：
生產環境的某程式由於某種bug，一直不會釋放日誌檔案，而分時寫入的日誌檔案又是有過期刪除機制的，這樣一直持續下去，就會發現伺服器上有大量的已過期刪除日誌檔案還占用著磁碟空間，直到產生磁碟滿風險。
掛載引發的懸案
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 /data12.2 測試驗證
如果還不放心的話，清理完資料再次掛載後，可以簡單測試下：
dd if=/dev/zero of=/data1 bs=1m count=200002.3 給個建議
針對根目錄這類離奇問題：建議在每次更換磁碟重新做掛載動作之前，檢查一下根目錄的空間使用情況；如果存在錯誤寫入資料的情況，需要及時清理，然後再進行新盤掛載，切記。
Linux磁碟爆滿 解決辦法
問題描述 阿里雲伺服器告警，磁碟爆滿。於是收到訊息去到根目錄下 df h 檢視，發現磁碟爆滿，100 然後去到根路徑下，du sh 發現這些檔案加一塊也達不到占用的空間大小 解決辦法 用lsof檢查後才發現原因是,有檔案被刪除,而程序還活著,因而造成還占用空間的現象。因此，需要把這些殭屍程序刪除掉，...
磁碟爆滿導致zookeeper卡住
場景復現 線上伺服器磁碟滿了導致部署在上面的namenode zookeeper kafka 均無法工作 丟擲異常，清理kafka備份檔案後系統磁碟還原了100g 但是此時的zookeeper節點已經無法再加入集群。3臺 zookeeper節點 出問題的節點在當時是作為leader工作的。錯誤日誌 ...
mysql 磁碟滿了 MySQL處理磁碟滿的方式
本文主要介紹了mysql響應磁碟滿錯誤的方式 如裝置上無剩餘空間 以及響應超配 額錯誤的方式 如寫入失敗或達到了使用者遮蔽限制 本文介紹的內容與寫入myisam表有關。它也適用於寫入二進位制日誌檔案和二進位制索引檔案，但對 row和record的應用應被視為event。本文主要介紹了mysql響應磁...