記一次查找Hdfs磁盤佔用空間比實際存儲文件大4倍的緣由

在一次主備namenode發生切換後，重啓datanode節點，發現磁盤空間很大，想清理一下磁盤，

經過命令Hdfs dfs -du -h --max-depth=1 / 發現實際文件的大小隻有8g，經過du -h --max-depth=1 /hadoop 發現磁盤佔用空間竟然有46g，即便我把hdfs文件所有刪掉，也只能釋放8G的空間，Hdfs佔用的磁盤空間如何釋放？

經查證，hdfs dfs -du查出來的空間是Namenode裏面記錄的文件大小，而datanode裏面存放有namenode沒有記錄的文件，二者不一樣步。這種狀況hdfs會經過datanode按期向namenode報告存儲狀況來解決，若是namenode發現datanode的存儲裏面包括不在他本身記錄在案的文件，會把此文件標記爲待刪除，會在NamenodeUI上面顯示爲pending deletion blocks，過1小時發送這樣的blocks給datanode，執行清除動做，清除成功後，namenodeUI上面pending deletion blocks變爲0，磁盤空間釋放。

在這個清除過程當中，若是待刪除的blocks過多，會致使二者通信超時。

修改hadoop配置參數(core-site.xml):

1. 設置 ipc.client.rpc-timeout.ms 爲 0，意思是永不超時；

2. 設置 ipc.maximum.data.length 爲 100,000,000，避免 datanode 發送 block report 失敗;

3. 設置 ipc.maximum.response.length 爲 100,000,000，避免 namenode 發送 pending deletion blocks 失敗。

爲何重啓 HDFS 後，系統一個小時後才變得不正常    由於咱們把 dfs.namenode.startup.delay.block.deletion.sec (hdfs-site.xml) 參數設置爲 3600，因此係統啓動後一小時內不進行塊刪除。

什麼緣由致使namenode與datanode文件不一致？standy namenode沒有及時同步active namenode，而後standy namenode成爲了active namenode，理論上Namenode直接從本地恢復fsimage信息，再從journal節點拿editlog恢復，不知道什麼緣由沒有恢復成功，丟失了datanode上面後寫入的文件信息。

網上也有 刪除大量文件後出現這個問題    這個跟HDFS原理相關。當咱們在HDFS中刪除文件時，namenode只是把目錄入口刪掉，而後把須要刪除的數據塊記錄到pending deletion blocks列表。當下一次datanode向namenode發送心跳的時候，namenode再把刪除命令和這個列表發送到datanode端。    因爲咱們刪除了大量文件，因此這個pending deletion blocks列表很長很長，致使了timeout。刪除失敗，可是namenode已經刪除了，datanode沒有成功刪除，磁盤空間沒釋放。