對於 linux 磁碟滿的問題，
我們通常的處理思路是用du查詢可清理的大檔案，
然後臨時刪掉讓磁碟使用率先降下來，從而盡快保證磁碟能繼續寫入。
但是，有一些情況的處理效果不太一樣，
du/df 呈現的結果可能還會讓人迷惑不解。
下面，我就分享下幾個工作中遇到過的較離奇的磁碟滿問題。
一、被忽略的隱藏檔案
1、認識 swapfile
linux 的交換檔案 swapfile 的產生場景較普遍，而且也是以隱藏檔案的形式存在的，
因此這裡主要聊聊 swapfile 這一類的隱藏檔案。
當用 vim 開啟乙個檔案時，都會產生乙個 .swp 的臨時隱藏交換檔案，用來備份緩衝區中的內容。
當檔案非正常關閉（比如直接關閉終端或者電腦斷電等）時，.swp檔案不會被刪除，這樣就可以用此檔案來恢復檔案。（注意當正常關閉時，此檔案會被刪除；且如果只是讀取檔案，不會產生 .swp 檔案）
而且，如果 vim 意外退出後，又重新開啟檔案二次編輯，
那麼舊的 .swp 檔案會繼續保留，並產生新的 .swo 臨時隱藏檔案。
如果二次編輯的時候，vim 又異常退出了，
那麼還會繼續產生新的臨時隱藏檔案.swn、.swm、 .swl …
2、處理建議
有些隱藏檔案的磁碟占用也挺大：
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 # 禁止在編輯時候產生此檔案；
但是注意這僅限於對檔案損失可以容忍的情況下；
如果不能容忍檔案損失，那還是建議還是開啟 swapfile：
vim /etc/vimrc
# 新增如下配置
set swapfile # 則是在編輯時候產生此檔案；
二、未釋放的已刪除檔案
1、du 和 df 不一致
如果隱藏檔案因素排除了，
還是發現 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 /data1
1解決。
解除安裝後，就會發現 /data1 目錄下確實有大量檔案，
刪除後，再 mount -a 重新掛載，
然後根目錄消失的磁碟空間，一般就能找回來了。
2.2 測試驗證
如果還不放心的話，清理完資料再次掛載後，可以簡單測試下：
通過dd if=/dev/zero of=/data1 bs=1m count=20000
往 /data1 大概寫個 20g 資料，
再觀察下根目錄的空間是否受影響，
如果不受影響就說明問題解決！
2.3 給個建議
針對根目錄這類離奇問題：
建議在每次更換磁碟重新做掛載動作之前，檢查一下根目錄的空間使用情況；
如果存在錯誤寫入資料的情況，需要及時清理，然後再進行新盤掛載，切記。
Linux磁碟空間檢視及空間滿的處理
如果要檢視磁碟還剩多少空間，當然是用df的命令了。root localhost df h 檔案系統 容量 已用 可用 已用 掛載點 dev sda2 14g 11g 2.6g 82 dev sda1 99m 14m 81m 14 boot tmpfs 442m 275m 168m 63 dev sh...
Linux磁碟空間檢視及空間滿的處理
以下 今天在執行r指令碼的時候報了個錯 fatal error cannot create r tempdir 排除了是自己寫的 的問題，想著應該是某個沒見過的原因，google之，發現網上的說法是 tmp資料夾佔滿了磁碟空間。執行 df 命令 第一次碰到這種情況，繼續google之，使用如下命令 ...
磁碟空間滿的問題
kinux os pc 出現磁碟空間不足問題有 導致該問題的可能原因包括 執行df h檢視磁碟使用 以及使用du sh 檢視 分析根目錄下每個目錄下面有多少個檔案。fori in doecho i find i wc l done df i 檢視實際inode 命令 命令重新建立檔案系統，指定ino...