下面的方法我基本可以保證，如果df和du顯示空間不一致，除了普遍的解決方法外，網路上你根本搜尋不到！除非你是linux高手！高手在此我們膜拜！
在分析df和du查到的結果不一樣之前，我們先來了解下linux的df和du命令有什麼不同。
這個大家可以從網上很直觀的搜尋到，一艘一大片，我們在這裡還是要囉嗦一下，為下面的解決方案做鋪墊。
現在我們假定儲存空間有10g，而我們準備刪除2g的資料，並假定這個檔案為1.txt
df命令：通過檔案系統快速的獲取空間大小的資訊，當我們刪除乙個檔案時，這個檔案不會立馬從linux系統中消失，而是等系統的服務或程式等徹底不用此檔案時，才會在系統中徹底被刪除。而假如你刪除了乙個檔案，此時的df依舊能統計到它占用儲存的大小。
比如我們刪除這個1.txt，然後我們的txt程式還正在開啟使用這個檔案，那麼此時，df查到的剩餘儲存是8g。
du命令：簡單的說，du和df一樣，只不過是它不統計已經刪除了的檔案，比如刪除1.txt，無論這個檔案現在是否被使用，它都認為被刪除了，此時執行du命令，查到的就是剩餘空間是10g。
區別就是，是否統計到已經被刪除的但還在被使用的檔案。那麼問題來了，如果df和du查到的結果不一樣，我們一般會認為，是不是因為服務或者程式正在占用已經刪除了的資料，於是網路上給了處理方法，利用如下命令：lsof |grep deleted 就可以檢視到已經刪除的，但是還沒其他服務占用的檔案。
但是問題來了，我的執行了上述命令後，並沒有所說的上圖的樣子，而是如下圖：
占用全部是0，我在網路上搜尋了眾多的資源，都沒有說出最終的解決辦法，因為大部分人認為，df和du顯示空間不一致，都是因為有程式或服務占用造成的，而我的並沒有占用，那麼就不是這個原因，重啟伺服器或伺服器根本不能解決這個問題。
重點來了！上面文章說過：df可以統計已經刪除的但還在被使用的，du不統計已經刪除的，那麼如果損壞的檔案會不會被統計呢？從解決這個問題上來講，損壞的檔案並不是被刪除，而是還存在的資源，但是df卻已經統計不到了，但du卻可以統計到，這個問題真是弄得我心力憔悴，我是怎麼發現這些檔案已經損壞了呢？當然用du命令檢視大檔案時發現的。
命令是：du -h --max-depth=1
紅框中的就是未被找到，暫時認為已經損壞的檔案。
既然上面的方法不能解決，那麼只能死馬當活馬醫，看看是不是因為損壞的檔案占用儲存空間導致的df和du空間不一致的問題。
於是乎，我們利用修復命令修復一下檔案系統：
命令如下： fsck -fyv /dev/vdb1
/dev/vdb1 是磁碟，你的可能是別的，請自己檢視。如果不能執行，那麼還請取消掛載然umount /www，再執行 fsck -fyv /dev/vdb1，如果成功，說明就是這個原因導致的，此時你再次執行df和du已經一樣，問題就找到了。成功後還請您再次重新掛載您的硬碟。
假如說，您不能umount 解除安裝您的硬碟，還請您vi /etc/fstab/ 看看是不是寫入了掛載資訊！這也是很多人沒有告訴你的哈！
df和du磁碟空間不一致
最近在伺服器上部署了一套服務，服務執行過程中不小心把日誌檔案給刪除了，測試了一下沒有影響服務的正常執行，而且沒有日誌後處理的操作就不以為意的扔那了，但不經意間也埋下了乙個巨大的坑。收到伺服器磁碟報警的時候就df看了一下滿了，但是du h看的時候發現才總共130g的磁碟採用了20g不到。df h 磁碟...
du 與df 統計系統磁碟不一致原因與解決方法
事件起因 同事發現雲主機磁碟系統盤滿了，準備清理系統盤，便利用du 命令統計了根目錄下各資料夾的大小，發現統計的各資料夾的大小總和 加起來比 df 命令檢視到的系統盤所使用空間 要小很多。這裡記錄下解決方法 了解下df與du的工作原理 dudu命令會對待統計檔案逐個呼叫fstat這個系統呼叫，獲取檔...
ls h du sh的大小顯示不一致原因
近期在學習中偶然發現 ls h du sh的大小顯示不一致具體如下 root localhost ll h 總用量 20k rw r r 1 root root 3.8k 1月 7 08 17 1.txt rw 1 root root 1.4k 4月 27 2020 anaconda ks.cfg ...