Mailing-List: contact hdfs-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hdfs-issues@hadoop.apache.org
Message-ID: <237720731.136551265674768177.JavaMail.jira@brutus.apache.org>
Date: Tue, 9 Feb 2010 00:19:28 +0000 (UTC)
From: "Todd Lipcon (JIRA)" <jira@apache.org>
To: hdfs-issues@hadoop.apache.org
Subject: [jira] Commented: (HDFS-955) FSImage.saveFSImage can lose edits
In-Reply-To: <1579366163.136111265673808259.JavaMail.jira@brutus.apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Todd Lipcon commented on HDFS-955:
----------------------------------

Konstantin: by any chance, do you have a document that describes the NN's startup protocol with regards to image loading? To make sure we've got the failure scenarios correct we need to match up the recovery protocol to all of the failure points I think (eg what happens with a half-written IMAGE_NEW, what happens if some dirs have _NEW and others don't, etc).

If no such document exists I'll go through the code to work on creating it, or at least a thorough JIRA comment we can reference from the code.

> FSImage.saveFSImage can lose edits
> ----------------------------------
>
>                 Key: HDFS-955
>                 URL: https://issues.apache.org/jira/browse/HDFS-955
>             Project: Hadoop HDFS
>          Issue Type: Bug
>    Affects Versions: 0.21.0, 0.22.0
>            Reporter: Todd Lipcon
>            Assignee: Todd Lipcon
>            Priority: Blocker
>
> This is a continuation of a discussion from HDFS-909. The FSImage.saveFSImage function (implementing dfsadmin -saveNamespace) can corrupt the NN storage such that all current edits are lost.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.