笔者的hadoop在不间断的写文件的过程中报了如下错误
经查看发现是hadoop所在服务器的磁盘空间不足导致的。
好了，知道问题后笔者需要配置相关参数来避免该问题
1、与mapred.local.dir相关的参数
* mapred.local.dir.minspacestart：在mapreduce运行任务之前，检查temporary 目录下是否还有该选项配置的空闲空间，如果少于该配置，则map或reduce task不会分配到该TaskTracker上，以避免由于磁盘空间不足导致的task失败。默认设置为0，disable该功能
* mapred.local.dir.minspacekill：如果该磁盘卷下剩余的磁盘空间不足该配置，则将正在运行的Task 杀掉。默认为0，diabled该功能
另，如果服务器有多个块设备最好将mapred.local.dir设置成多个目录，每个目录对应一个块设备，这样多个task在同一个TaskTracker上运行的时候，就可以分别写不同的磁盘写入点，以增大作业运行的磁盘吞吐率。
2、与dfs.data.dir相关的参数
* dfs.datanode.du.reserved：dfs写文件块时，如果当前datanode上的dfs.data.dir下剩余磁盘空间不足该选项配置的空间大小，就不往该datanode继续写数据块
* dfs.datanode.du.pct：同dfs.datanode.du.reserved，不过配置值为一个百分比
最好预留些空间，避免写文件失败。
3、建议配额
mapred.local.dir.minspacestart = slots * dfs.block.size
mapred.local.dir.minspacekill = slots/2 * dfs.block.size
dfs.datanode.du.reserved = dfs.block.size * dfs.replication #最少留这么多吧，建议留大些。
根据需求，笔者在hdfs-site.xml中配置了
<property>
<name>dfs.datanode.du.reserved</name>
<value>209715200</value>
</property>
然后重启hadoop。但是！！！在这个时候笔者干了件非常愚蠢的事情，format了namenode！ 是的就是这么任性的格式化了。。。
这导致tmp/hadoop-root/dfs/name生成了新的clusterID，同时format后的启动hadoop经常会包如下错误（hadoop-root-datanode-dongsys-hadoop.log）： 
这事因为format格式化的时候会在name下生成新的clusterID，而不会改变data下的clusterID，name和data下的clusterID不一致导致。这时候我们将修改data的clusterID同name的clusterID一致，然后重启hadoop即可。
===================================================================
在里，笔者要曾经尝试，“恢复”格式化的数据。实际上format只是生成新的clusterID和blockpoolID。这里笔者将name和data中涉及到的blockpoolID以及namespaceID都修改成所需恢复的对呀data目录下VERSION的数据。
比如笔者格式化前的datanode是BP-19792352-192.168.1.118-1422543381350。那么BP-19792352-192.168.1.118-1422543381350/current/VERSION里的信息是
namespaceID=846434132
cTime=0
blockpoolID=BP-19792352-192.168.1.118-1422543381350
layoutVersion=-56
将name/current/VERSION的namespaceID、blockpoolID都修改成和上面的信息一致，然后重启hadoop，结果Configured Capacity、DFS Used、Non DFS Used等信息都正确了，但是实际上所以的datanode下文件都是无法正常读取到的。
这里笔者还不知道是为什么，希望有知晓的朋友告知下，笔者也会继续学习hadoop需找答案。
