Mailing-List: contact hdfs-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hdfs-issues@hadoop.apache.org
Date: Mon, 3 Feb 2014 11:02:10 +0000 (UTC)
From: "Harsh J (JIRA)" <jira@apache.org>
To: hdfs-issues@hadoop.apache.org
Message-ID: <JIRA.12400058.1215723830493.26479.1391425330961@arcas>
In-Reply-To: <JIRA.12400058.1215723830493@arcas>
References: <JIRA.12400058.1215723830493@arcas>
Subject: [jira] [Resolved] (HDFS-184) SecondaryNameNode doCheckpoint()
 renames current directory before asking NameNode to rollEditLog()
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/HDFS-184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Harsh J resolved HDFS-184.
--------------------------

    Resolution: Not A Problem

This doesn't appear to be a problem today, esp. after the new edits and fsimage retention style, as we do rollEditLog as the first-thing before any other local operation.

Likely gone stale. Closing out for now as 'Not A Problem' (anymore).

> SecondaryNameNode doCheckpoint() renames current directory before asking NameNode to rollEditLog()
> --------------------------------------------------------------------------------------------------
>
>                 Key: HDFS-184
>                 URL: https://issues.apache.org/jira/browse/HDFS-184
>             Project: Hadoop HDFS
>          Issue Type: Bug
>            Reporter: Lohit Vijayarenu
>            Priority: Minor
>
> In SecondaryNameNode doCheckPoint() function invokes _startCheckpoint()_ before calling _namenode.rollEditLog()_
> _startCheckpoint()_ internally invokes _CheckpointStorage::startCheckpoint()_ which renames current to lastcheckpoint.tmp. if call to namenode failed, then we would redo the above step renaming empty current directory in next iteration? Should we remove after we know namenode has successfully rolled edits?


--
This message was sent by Atlassian JIRA
(v6.1.5#6160)