[
https://issues.apache.org/jira/browse/HADOOP-3576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lohit Vijayarenu updated HADOOP-3576:
-------------------------------------
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
{noformat}
[lohit@ hadoop-core-trunk]$ ./bin/hadoop dfs -mv /a/b /a/b/c
mv: java.io.IOException: java.lang.NullPointerException
[lohit@ hadoop-core-trunk]$
{noformat}
After this, the namespace of /a/b is gone
{noformat}
[lohit@ hadoop-core-trunk]$ ./bin/hadoop dfs -lsr /a
[lohit@ hadoop-core-trunk]$
{noformat}
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.
{noformat}
[lohit@ hadoop-core-trunk]$ ./bin/hadoop dfs -rmr /a
Deleted hdfs://jamba.juice:8020/a
[lohit@ hadoop-core-trunk]$
{noformat}
But, restarting now, throws an exception on NameNode and NameNode wouldn't
start.
{noformat}
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)
{noformat}
In hadoop 0.17, we never allowed such a move.
{noformat}
[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]$
{noformat}
This is the issue seen with HADOOP-3561. Opening this JIRA to fix the
underlying problem while HADOOP-3561 could be committed.
was:
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
{noformat}
[lohit@ hadoop-core-trunk]$ ./bin/hadoop dfs -mv /a/b /a/b/c
mv: java.io.IOException: java.lang.NullPointerException
[lohit@ hadoop-core-trunk]$
{noformat}
After this, the namespace of /a/b is gone
{noformat}
[lohit@ hadoop-core-trunk]$ ./bin/hadoop dfs -lsr /a
[lohit@ hadoop-core-trunk]$
{noformat}
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.
{noformat}
[lohit@ hadoop-core-trunk]$ ./bin/hadoop dfs -rmr /a
Deleted hdfs://ucdev27.inktomisearch.com/a
[lohit@ hadoop-core-trunk]$
{noformat}
But, restarting now, throws an exception on NameNode and NameNode wouldn't
start.
{noformat}
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)
{noformat}
In hadoop 0.17, we never allowed such a move.
{noformat}
[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]$
{noformat}
This is the issue seen with HADOOP-3561. Opening this JIRA to fix the
underlying problem while HADOOP-3561 could be committed.
> hadoop dfs -mv throws NullPointerException
> ------------------------------------------
>
> Key: HADOOP-3576
> URL: https://issues.apache.org/jira/browse/HADOOP-3576
> Project: Hadoop Core
> Issue Type: Bug
> Components: dfs
> Affects Versions: 0.18.0
> Reporter: Lohit Vijayarenu
> Assignee: Hairong Kuang
> Fix For: 0.18.0
>
>
> 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
> {noformat}
> [lohit@ hadoop-core-trunk]$ ./bin/hadoop dfs -mv /a/b /a/b/c
> mv: java.io.IOException: java.lang.NullPointerException
> [lohit@ hadoop-core-trunk]$
> {noformat}
> After this, the namespace of /a/b is gone
> {noformat}
> [lohit@ hadoop-core-trunk]$ ./bin/hadoop dfs -lsr /a
> [lohit@ hadoop-core-trunk]$
> {noformat}
> 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.
> {noformat}
> [lohit@ hadoop-core-trunk]$ ./bin/hadoop dfs -rmr /a
> Deleted hdfs://jamba.juice:8020/a
> [lohit@ hadoop-core-trunk]$
> {noformat}
> But, restarting now, throws an exception on NameNode and NameNode wouldn't
> start.
> {noformat}
> 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)
> {noformat}
> In hadoop 0.17, we never allowed such a move.
> {noformat}
> [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]$
> {noformat}
> This is the issue seen with HADOOP-3561. Opening this JIRA to fix the
> underlying problem while HADOOP-3561 could be committed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
