Mailing-List: contact hdfs-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hdfs-issues@hadoop.apache.org
Date: Thu, 12 May 2011 19:35:47 +0000 (UTC)
From: "Aaron T. Myers (JIRA)" <jira@apache.org>
To: hdfs-issues@hadoop.apache.org
Message-ID: 
 <334032762.7872.1305228947635.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <329604580.5336.1305155987445.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (HDFS-1921) Save namespace can cause NN to be
 unable to come up on restart
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/HDFS-1921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13032608#comment-13032608 ] 

Aaron T. Myers commented on HDFS-1921:
--------------------------------------

Hey Matt, that's great news. Thanks for picking this up. 

I just talked to Todd, and he agrees that this code will be superseded in 0.23 by the work that's going on HDFS-1073. So, I think it's reasonable to only work on a patch for 0.22 as part of this JIRA.

> Save namespace can cause NN to be unable to come up on restart
> --------------------------------------------------------------
>
>                 Key: HDFS-1921
>                 URL: https://issues.apache.org/jira/browse/HDFS-1921
>             Project: Hadoop HDFS
>          Issue Type: Bug
>    Affects Versions: 0.22.0, 0.23.0
>            Reporter: Aaron T. Myers
>            Assignee: Matt Foley
>            Priority: Blocker
>             Fix For: 0.22.0, 0.23.0
>
>
> I discovered this in the course of trying to implement a fix for HDFS-1505.
> Per the comment for {{FSImage.saveNamespace(...)}}, the algorithm for save namespace proceeds in the following order:
> # rename current to lastcheckpoint.tmp for all of them,
> # save image and recreate edits for all of them,
> # rename lastcheckpoint.tmp to previous.checkpoint.
> The problem is that step 3 occurs regardless of whether or not an error occurs for all storage directories in step 2. Upon restart, the NN will see non-existent or corrupt {{current}} directories, and no {{lastcheckpoint.tmp}} directories, and so will conclude that the storage directories are not formatted.
> This issue appears to be present on both 0.22 and 0.23. This should arguably be a 0.22/0.23 blocker.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira