接上一篇。
十二、如果遇到如下错误：
FAILED java.lang.IllegalArgumentException: java.net.URISyntaxException: Relative path in absolute URI:***
就是URI里边出现了不允许出现的字符，比如冒号：之类的，操作系统不允许的文件命名字符。详细的可以根据提示的部分（星号部分）来进行grep匹配查看。消除掉就可以解决了。
十三、遇到tasktracker无法启动，tasktracker日志报错如下：
ERROR org.apache.hadoop.mapred.TaskTracker: Can not start task tracker because java.net.BindException: Address already in use ***
是端口被占用或者已经有相应的进程启动了，这时候你先停止集群，然后使用ps -aux | grep hadoop 命令，来看看相关的hadoop进程，把hadoop相关的守护进程kill掉即可。
十四、遇到datanode无法启动的情况，datanode日志报错如下：
ERROR org.apache.hadoop.hdfs.server.datanode.DataNode: java.io.IOException: No locks available
网上有许多说需要format，个人感觉是扯淡，因为我同样的添加节点，添加的其他节点没有问题，只有一个有问题，所以问题一定不在是否format身上，而且如果format后hdfs内的数据就会全部丢失，我也不会去尝试这种方法。详细看了一下，apache的邮件列表有这样一段内容：
No locks available can mean that you are trying to use hadoop on a filesystem that does not support file level locking. Are you trying to run your name node storage in NFS space?
这里提到文件级锁的情况，使用
$ /etc/init.d/nfs status
命令查看网络文件系统的情况，都是关闭的。另外使用df -Th或者mount命令可以查看文件系统的类型，得到的结果确实是NFS文件系统的问题。不能使用挂在的网络文件系统，因为又貌似只读的情况，即便不是只读情况，也像上边说的，是不支持file级锁的。
最后解决办法，可以尝试给nfs添加文件级的锁。我这里就是修改dfs.data.dir，不使用nfs完事了。
十五、datanode died，并且无法启动该进程，log报如下错误：
2012-06-04 10:31:34,915 INFO org.apache.hadoop.hdfs.server.common.Storage: Cannot access storage directory /data5/hadoop_data
2012-06-04 10:31:34,915 INFO org.apache.hadoop.hdfs.server.common.Storage: Storage directory /data5/hadoop_data does not exist.
2012-06-04 10:31:35,033 ERROR org.apache.hadoop.hdfs.server.datanode.DataNode: org.apache.hadoop.util.DiskChecker$DiskErrorException: Invalid value for volsFailed : 2 , Volumes tolerated : 0
我的这个问题，查到原因是该节点的磁盘变成的只读（only read）模式，网上搜了一下发现这种情况还蛮多，Linux机器的硬盘本来都是设置成读写(Read/Write)方式的，不过偶尔会发现自动变成了只读(Read Only)，查了一些资料，发生这种情况的原因有多种，可能的问题：
- 文件系统错误
- 内核相关硬件驱动bug
- FW固件类问题
- 磁盘坏道
- 硬盘背板故障
- 硬盘线缆故障
- HBA卡故障
- RAID卡故障
- inode资源耗尽
解决的办法：
- 重启服务器（命令reboot）
- 重新mount硬盘
- fsck尝试修复
- 更换硬盘
附一个详细的解决办法（未尝试，看着挺靠谱的）。
十六、jps无法查看到hadoop、hbase的daemon守护进程，但是hadoop、hbase均工作正常，web页面也能访问，用ps -ef|grep java 也能看到启动的java进程。
造成这个情况的原因是java程序启动后，默认（请注意是默认）会在/tmp/hsperfdata_userName目录下以该进程的id为文件名新建文件，并在该文件中存储jvm运行的相关信息，其中的userName为当前的用户名，/tmp/hsperfdata_userName目录会存放该用户所有已经启动的java进程信息。对于windows机器/tmp用Windows存放临时文件目录代替。而jps、jconsole、jvisualvm等工具的数据来源就是这个文件（/tmp/hsperfdata_userName/pid)。所以当该文件不存在或是无法读取时就会出现jps无法查看该进程号，jconsole无法监控等问题。
所以如果你的tmp有定期清空、磁盘满、写入权限等情况，均会造成jps无法查看java进程的情况，需要解决的可以设置缓存的保存位置。关于设置该文件位置的参数为-Djava.io.tmpdir
另外：
/tmp/hsperfdata_userName/pid文件会在对应java进程退出后被清除。如果java进程非正常退出（如kill -9），那么pid文件会被保留，直到执行一次java命令或是加载了jvm程序的命令（如jps、javac、jstat），会将所有无用的pid文件都清除掉
十七、执行mapreduce任务的时候报错如下：
2012-06-21 10:50:43,290 WARN org.mortbay.log: /mapOutput: org.apache.hadoop.util.DiskChecker$DiskErrorException: Could not find taskTracker/hadoop/jobcache/job_201206191809_0004/attempt_201206191809_0004_m_000006_0/output/file.out.index in any of the configured local directories
2012-06-21 10:50:45,592 WARN org.apache.hadoop.mapred.TaskTracker: getMapOutput(attempt_201206191809_0004_m_000006_0,0) failed : org.apache.hadoop.util.DiskChecker$DiskErrorException: Could not find taskTracker/ha.doop/jobcache/job_201206191809_0004/attempt_201206191809_0004_m_000006_0/output/file.out.index in any of the configured local directories
虽然是两个warn，但是也影响作业效率，所以还是尝试解决一下，错误原因是无法找到作业的中间输出文件。需要作如下检查：
a、配置mapred.local.dir属性
b、df -h 看看缓存路径下的空间是否足够
c、free 看看内存空间是否足够
d、确保缓存路径可写权限
e、检查磁盘损坏
namenode循环报错如下：
2012-08-21 09:20:24,486 WARN org.apache.hadoop.hdfs.server.namenode.FSNamesystem: Cannot roll edit log, edits.new files already exists in all healthy directories:
/data/work/hdfs/name/current/edits.new
/backup/current/edits.new
2012-08-21 09:20:25,357 ERROR org.apache.hadoop.security.UserGroupInformation: PriviledgedActionException as:hadoop cause:java.net.ConnectException: Connection refused
2012-08-21 09:20:25,357 ERROR org.apache.hadoop.security.UserGroupInformation: PriviledgedActionException as:hadoop cause:java.net.ConnectException: Connection refused
2012-08-21 09:20:25,359 WARN org.mortbay.log: /getimage: java.io.IOException: GetImage failed. java.net.ConnectException: Connection refused
secondarynamenode也有相关错误。
搜到一个说法原因是：
With 1.0.2, only one checkpoint process is executed at a time. When the namenode gets an overlapping checkpointing request, it checks edit.new in its storage directories. If all of them have this file, namenode concludes the previous checkpoint process is not done yet and prints the warning message you've seen.
这样的话如果你确保edits.new文件是之前错误操作残留下的没有用的文件的话，那么可以删掉，检测之后是否还有这样的问题。
另外请确保namenode的hdfs-site.xml的配置有如下项：
<property>
<name>dfs.secondary.http.address</name>
<value>0.0.0.0:50090</value>
</property>
将上述的0.0.0.0修改为你部署secondarynamenode的主机名
secondarynamenode的hdfs-site.xml有如下项：
<property>
<name>dfs.http.address</name>
<value>0.0.0.0:50070</value>
</property>
将上述的0.0.0.0修改为你部署namenode的主机名