[ http://issues.apache.org/jira/browse/HADOOP-56?page=comments#action_12367686 ]
Doug Cutting commented on HADOOP-56: ------------------------------------ I see two cases: 1. A namenode has been misconfigured, and comes up knowing about no files. When datanodes report their blocks, the namenode tells them those blocks belong to no files, so the datanode removes them. This is bad. 2. A datanode has been moved to a new cluster, or is rebooted after a long downtime. It comes up and tells the namenode about the blocks that it has. The namenode tells it that those blocks belong to no files, so the datanode removes them. This is good. So perhaps the thing to fix is that the namenode should not automatically create an empty filesystem if it is misconfigured. Perhaps instead we should have a separate "format" command that creates an empty filesystem, and one must run this the first time before starting dfs. How does that sound? It makes the out-of-box experience a little more awkward, but I think it might be warranted in this case. > hadoop nameserver does not recognise ndfs nameserver image > ---------------------------------------------------------- > > Key: HADOOP-56 > URL: http://issues.apache.org/jira/browse/HADOOP-56 > Project: Hadoop > Type: Bug > Components: dfs > Versions: 0.1 > Reporter: Yoram Arnon > Priority: Critical > Attachments: ndfs.tar.gz > > hadoop nameserver does not recognise ndfs image > Thus, upgrading from ndfs to hadoop dfs results in total data loss. > The upgrade should be seemless, with the new server recognising all previous > version that are not end-of-life'd. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
