记一次查找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没有成功删除，磁盘空间没释放。