Details
-
Bug
-
Status: Closed
-
Blocker
-
Resolution: Fixed
-
0.18.0
-
None
-
None
-
Reviewed
Description
hadoop dfs -mv command throws NullPointerException while moving a directory to its subdirecotry. In 0.17 version, such a move was not allowed.
Consider the example
[lohit@ hadoop-core-trunk]$ ./bin/hadoop dfs -mv /a/b /a/b/c mv: java.io.IOException: java.lang.NullPointerException [lohit@ hadoop-core-trunk]$
After this, the namespace of /a/b is gone
[lohit@ hadoop-core-trunk]$ ./bin/hadoop dfs -lsr /a [lohit@ hadoop-core-trunk]$
Restarting the namenode recovers this namespace and everything seems to be normal.
On the other hand, before restarting the namenode, if we delete the directory /a, it succeeds.
[lohit@ hadoop-core-trunk]$ ./bin/hadoop dfs -rmr /a Deleted hdfs://jamba.juice:8020/a [lohit@ hadoop-core-trunk]$
But, restarting now, throws an exception on NameNode and NameNode wouldn't start.
2008-06-17 00:58:50,422 ERROR org.apache.hadoop.dfs.NameNode: java.lang.NullPointerException at org.apache.hadoop.dfs.FSNamesystem.changeLease(FSNamesystem.java:4339) at org.apache.hadoop.dfs.FSEditLog.loadFSEdits(FSEditLog.java:561) at org.apache.hadoop.dfs.FSImage.loadFSEdits(FSImage.java:846) at org.apache.hadoop.dfs.FSImage.loadFSImage(FSImage.java:675) at org.apache.hadoop.dfs.FSImage.recoverTransitionRead(FSImage.java:289) at org.apache.hadoop.dfs.FSDirectory.loadFSImage(FSDirectory.java:80) at org.apache.hadoop.dfs.FSNamesystem.initialize(FSNamesystem.java:273) at org.apache.hadoop.dfs.FSNamesystem.<init>(FSNamesystem.java:252) at org.apache.hadoop.dfs.NameNode.initialize(NameNode.java:148) at org.apache.hadoop.dfs.NameNode.<init>(NameNode.java:193) at org.apache.hadoop.dfs.NameNode.<init>(NameNode.java:179) at org.apache.hadoop.dfs.NameNode.createNameNode(NameNode.java:825) at org.apache.hadoop.dfs.NameNode.main(NameNode.java:834)
In hadoop 0.17, we never allowed such a move.
[lohit@ branch-0.17]$ ./bin/hadoop dfs -mv /a/b /a/b/c mv: Failed to rename /a/b to /a/b/c [lohit@ branch-0.17]$
This is the issue seen with HADOOP-3561. Opening this JIRA to fix the underlying problem while HADOOP-3561 could be committed.
Attachments
Attachments
Issue Links
- is related to
-
HADOOP-3561 With trash enabled, 'hadoop fs -rmr .' still fully deletes the working dir
- Closed