hadoop-hdfs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Harsh J (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (HDFS-184) SecondaryNameNode doCheckpoint() renames current directory before asking NameNode to rollEditLog()
Date Mon, 03 Feb 2014 11:02:11 GMT

     [ 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)

Mime
View raw message