1. dfs.datanode.du.reserved
每块磁盘保留的空余空间，应预留一些给非hdfs文件使用，默认值为0，其单位为字节。那么实际可用于HDFS的存储空间就是；总存储空间-dfs.datanode.du.reserved。
如果此参数配置为10G，则df -h得出如下结果：
Filesystem Size Used Avail Use% Mounted on
/dev/sda4 243G 200G 31G 87% /data
注：总容量为243Ｇ，已使用200Ｇ，可用31Ｇ。使用量+可用量！＝总容量，少了１2Ｇ，这就是问题所在。
继续通过命令hadoop dfsadmin -report查看HDFS情况：
Configured Capacity: 228260941824 (232.58 GB)
DFS Used: 208414818078 (194.10 GB)
Non DFS Used: 0 (0 B)
DFS Remaining: 19846123746 (38.48 GB)
Configured Capacity显示的dfs.data.dir指定的目录空间总容量大小，则DFS Remaining应为232.58－194.10＝38.48Ｇ，但实际上仅仅为18.48G，这是为什么？因为实际上/dev/sda4可用空间只剩31Ｇ，但DFS Remaining却可以放38.48G的数据，所以有数据的话会一直会存入该节点，直到放满。
解决方法：将dfs.datanode.du.reserved设置更大。目前设置为30Ｇ
这样，hadoop dfsadmin -report查看
Configured Capacity: 228260941824 (212.58 GB)
DFS Used: 208414818078 (194.10 GB)
Non DFS Used: 0 (0 B)
DFS Remaining: 19846123746 (18.48 GB)
dfs可用空间18.48<31Ｇ，所以当dfs全部用完，磁盘/dev/sda4还是有13Ｇ空间空闲，达到要的效果!
2. dfs.datanode.max.transfer.threads
表示datanode上负责进行文件操作的线程数。如果需要处理的文件过多，而这个参数设置得过低就会有一部分文件处理不过来，就会报异常。
linux系统中所有的文件操作都被绑定到一个socket上，进一步具体可以把他看做是一个线程。而这个参数就是指定这种线程的个数。在datanode里面有一个专门的线程组来维护这些线程，同时有一个守护线程来监视这个线程组的体量，它负责监测线程数量是否到达上线，超过就抛出异常。因为如果这样的线程过多，系统内存就会暴掉。
dfs.datanode.max.xcievers属性表示每个datanode任一时刻可以打开的文件数量上限。此数目不能大于系统打开文件数的设置，即/etc/security/limits.conf中nofile的数值。
3.dfs.datanode.handler.count
datanode同时可以处理来着客户端的请求线程数，默认为10，如果集群规模比较大或者同时跑的任务比较多，建议增大此值。