应该原因是因为宕机，恢复后要保证3份复制，就把其他节点上的块写入到这个节点，但是这个节点上块已经存在了，要做recover或者 delete，datanode会对已经存在的blk先判断权限。然后进到存储路径下查看，有些blk的权限是664，有些则是644，644则无法 recover或者delete。于是把644的改为664，就不再报这个错误，或者把644的块写脚本删除也可以。至于怎么产生的644权限文件，还没 弄明白。异常抛多了，GC不能快速回收内存，DN就OOM了。不过，正常的块文件和块meta的权限应该是664，而datanode自己哈希出来的 subdir，权限应该都是775，subdir下面的块应该也是664。然后调大hadoop-env.sh里面的HADOOP_HEAPSIZE和 HADOOP_CLIENT_OPTS的内存数值。
另外记录关于一个hive的事，最近别的部门用phpHiveAdmin查询数据的人总跑过来说半天不出结果，也没有进度。翻看了一下Hive的配 置文件，这事是这样，hive 0.10.0为了执行效率考虑，简单的查询，就是只是select，不带count,sum,group by这样的，都不走map/reduce，直接读取hdfs文件进行filter过滤。这样做的好处就是不新开mr任务，执行效率要提高不少，但是不好的 地方就是用户界面不友好，有时候数据量大还是要等很长时间，但是又没有任何返回。
改这个很简单，在hive-site.xml里面有个配置参数叫
hive.fetch.task.conversion
将这个参数设置为more，简单查询就不走map/reduce了，设置为minimal，就任何简单select都会走map/reduce。