吐个hdfs的槽
其实每个 open source 的玩意儿都会有这个那个的 bug 的，但是这次白白花了一天半的时间，正经活没干，实在是很想吐一个槽。
我们有一个hadoop的机群，最开始是一堆配置低的 pizzabox，每台box有俩 disk，后来加了一些高配置的 beefbox，自从那个之后我们的 cluster 就没有平衡过，亏得于 HDFS-6621 所赐，Balancer 就是一龟速。这也就算了，反正我们也不着急，让他慢慢平衡呗～
然后周四早上，有些 pizzabox 的 disk 就满了，但 cluster 的 utilization 只有不到 50%。我们就怀疑各种 config 问题，比如是不是 dfs.datanode.fsdataset.volume.choosing.policy 设成 Round Robin 啦（之前被咬过），dfs.datanode.available-space-volume-choosing-policy.balanced-space-preference-fraction 是不是没设对，或者 dfs.datanode.du.reserved 是不是设太小了。总之排查了一番没有找出什么问题，就先看看 hdfs 能不能自己把几个 volume 之间 balance 一下，就翻到了这个 HDFS-1312 已经开了5年的 task 到现在还是悬而未决。
好吧，那我们就手动搞一下，参照 Hadoop 的 FAQ，貌似也不复杂，只要把 datanode 关掉，挪一下 subdir 到另一个磁盘同样的文件目录下就好了。我们也就这么做了，datanode 上线之后倒是 ok 了，磁盘多了点空余空间，我们很高兴，于是把其他的有问题的 box 都这么搞了。结果过了不久，我们就注意到磁盘又开始满了，我们心中就一股 WTF…
然后我们又开始一顿排查，又是看源码又是 debug 的，觉得 datanode 没有问题，新 block 也是写到另一个磁盘的。折腾了很久，然后我去比对了一下文件，发现了 dncp_block_verification.log.curr 居然有 1 TB !
所以我们是撞到了这个 HDFS-6114，我们挪了多少 block，丫又会写一堆 scan log 让我们一阵白挪….. 心里真的是万马奔腾…..
想想 Hadoop 也是有 10 年历史了，怎么还能这么不靠谱……..