You are viewing a plain text version of this content. The canonical link for it is here.
Posted to hdfs-issues@hadoop.apache.org by "Todd Lipcon (JIRA)" <ji...@apache.org> on 2011/05/26 01:38:49 UTC
[jira] [Created] (HDFS-2001) HDFS-1073: Kill previous.checkpoint,
lastcheckpoint.tmp directories
HDFS-1073: Kill previous.checkpoint, lastcheckpoint.tmp directories
-------------------------------------------------------------------
Key: HDFS-2001
URL: https://issues.apache.org/jira/browse/HDFS-2001
Project: Hadoop HDFS
Issue Type: Sub-task
Reporter: Todd Lipcon
Assignee: Todd Lipcon
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (HDFS-2001) HDFS-1073: Kill previous.checkpoint,
lastcheckpoint.tmp directories
Posted by "Todd Lipcon (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HDFS-2001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Todd Lipcon resolved HDFS-2001.
-------------------------------
Resolution: Fixed
Hadoop Flags: [Reviewed]
Committed to branch, thanks for reviewing, Eli
> HDFS-1073: Kill previous.checkpoint, lastcheckpoint.tmp directories
> -------------------------------------------------------------------
>
> Key: HDFS-2001
> URL: https://issues.apache.org/jira/browse/HDFS-2001
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: name-node
> Affects Versions: Edit log branch (HDFS-1073)
> Reporter: Todd Lipcon
> Assignee: Todd Lipcon
> Fix For: Edit log branch (HDFS-1073)
>
> Attachments: hdfs-2001.txt
>
>
> In the old design for edits/image storage, the secondary namenode does a complicated dance of moving "current/" to "lastcheckpoint.tmp", checkpointing into "current/", then moving "lastcheckpoint.tmp" back to "previous.checkpoint". The idea here was so that there would always be one directory with a valid set of storage files.
> In the HDFS-1073 design, this complicated dance isn't necessary. If a checkpoint fails, we can just rm that single fsimage_N.ckpt file and still be left with a valid storage directory.
> So, we can just let the 2NN keep a single current/ dir around for all checkpoints and eliminate the complexity of the dance.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HDFS-2001) HDFS-1073: Kill previous.checkpoint,
lastcheckpoint.tmp directories
Posted by "Todd Lipcon (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HDFS-2001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13039568#comment-13039568 ]
Todd Lipcon commented on HDFS-2001:
-----------------------------------
I let it loop for a while and it did somewhere around 150,000 distinct checkpoints coming from two NNs (of a very small image). I think this is pretty stable / good to go.
> HDFS-1073: Kill previous.checkpoint, lastcheckpoint.tmp directories
> -------------------------------------------------------------------
>
> Key: HDFS-2001
> URL: https://issues.apache.org/jira/browse/HDFS-2001
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: name-node
> Affects Versions: Edit log branch (HDFS-1073)
> Reporter: Todd Lipcon
> Assignee: Todd Lipcon
> Fix For: Edit log branch (HDFS-1073)
>
> Attachments: hdfs-2001.txt
>
>
> In the old design for edits/image storage, the secondary namenode does a complicated dance of moving "current/" to "lastcheckpoint.tmp", checkpointing into "current/", then moving "lastcheckpoint.tmp" back to "previous.checkpoint". The idea here was so that there would always be one directory with a valid set of storage files.
> In the HDFS-1073 design, this complicated dance isn't necessary. If a checkpoint fails, we can just rm that single fsimage_N.ckpt file and still be left with a valid storage directory.
> So, we can just let the 2NN keep a single current/ dir around for all checkpoints and eliminate the complexity of the dance.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HDFS-2001) HDFS-1073: Kill previous.checkpoint,
lastcheckpoint.tmp directories
Posted by "Todd Lipcon (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HDFS-2001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Todd Lipcon updated HDFS-2001:
------------------------------
Attachment: hdfs-2001.txt
This patch goes on top of HDFS-1991 and HDFS-1994.
It removes the previouscheckpoint/lastcheckpoint directories and updates TestDFSStorageStateRecovery to match that.
I currently commented out a couple of the test cases in TestSaveNamespace which need to still be updated and improved on this branch.
I also added a new test case for the scenario when the 2NN fails two checkpoints in a row. Previous to this patch, there was a bug with that situation, but this patch addresses it.
With this patch, I'm able to run a stress test with two 2NNs checkpointing as fast as they can for a while without issues. I'll let it loop for a few hours tonight.
> HDFS-1073: Kill previous.checkpoint, lastcheckpoint.tmp directories
> -------------------------------------------------------------------
>
> Key: HDFS-2001
> URL: https://issues.apache.org/jira/browse/HDFS-2001
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: name-node
> Affects Versions: Edit log branch (HDFS-1073)
> Reporter: Todd Lipcon
> Assignee: Todd Lipcon
> Fix For: Edit log branch (HDFS-1073)
>
> Attachments: hdfs-2001.txt
>
>
> In the old design for edits/image storage, the secondary namenode does a complicated dance of moving "current/" to "lastcheckpoint.tmp", checkpointing into "current/", then moving "lastcheckpoint.tmp" back to "previous.checkpoint". The idea here was so that there would always be one directory with a valid set of storage files.
> In the HDFS-1073 design, this complicated dance isn't necessary. If a checkpoint fails, we can just rm that single fsimage_N.ckpt file and still be left with a valid storage directory.
> So, we can just let the 2NN keep a single current/ dir around for all checkpoints and eliminate the complexity of the dance.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HDFS-2001) HDFS-1073: Kill previous.checkpoint,
lastcheckpoint.tmp directories
Posted by "Todd Lipcon (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HDFS-2001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Todd Lipcon updated HDFS-2001:
------------------------------
Component/s: name-node
Description:
In the old design for edits/image storage, the secondary namenode does a complicated dance of moving "current/" to "lastcheckpoint.tmp", checkpointing into "current/", then moving "lastcheckpoint.tmp" back to "previous.checkpoint". The idea here was so that there would always be one directory with a valid set of storage files.
In the HDFS-1073 design, this complicated dance isn't necessary. If a checkpoint fails, we can just rm that single fsimage_N.ckpt file and still be left with a valid storage directory.
So, we can just let the 2NN keep a single current/ dir around for all checkpoints and eliminate the complexity of the dance.
Affects Version/s: Edit log branch (HDFS-1073)
Fix Version/s: Edit log branch (HDFS-1073)
> HDFS-1073: Kill previous.checkpoint, lastcheckpoint.tmp directories
> -------------------------------------------------------------------
>
> Key: HDFS-2001
> URL: https://issues.apache.org/jira/browse/HDFS-2001
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: name-node
> Affects Versions: Edit log branch (HDFS-1073)
> Reporter: Todd Lipcon
> Assignee: Todd Lipcon
> Fix For: Edit log branch (HDFS-1073)
>
>
> In the old design for edits/image storage, the secondary namenode does a complicated dance of moving "current/" to "lastcheckpoint.tmp", checkpointing into "current/", then moving "lastcheckpoint.tmp" back to "previous.checkpoint". The idea here was so that there would always be one directory with a valid set of storage files.
> In the HDFS-1073 design, this complicated dance isn't necessary. If a checkpoint fails, we can just rm that single fsimage_N.ckpt file and still be left with a valid storage directory.
> So, we can just let the 2NN keep a single current/ dir around for all checkpoints and eliminate the complexity of the dance.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HDFS-2001) HDFS-1073: Kill previous.checkpoint,
lastcheckpoint.tmp directories
Posted by "Eli Collins (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HDFS-2001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13040415#comment-13040415 ]
Eli Collins commented on HDFS-2001:
-----------------------------------
+1 lgtm
> HDFS-1073: Kill previous.checkpoint, lastcheckpoint.tmp directories
> -------------------------------------------------------------------
>
> Key: HDFS-2001
> URL: https://issues.apache.org/jira/browse/HDFS-2001
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: name-node
> Affects Versions: Edit log branch (HDFS-1073)
> Reporter: Todd Lipcon
> Assignee: Todd Lipcon
> Fix For: Edit log branch (HDFS-1073)
>
> Attachments: hdfs-2001.txt
>
>
> In the old design for edits/image storage, the secondary namenode does a complicated dance of moving "current/" to "lastcheckpoint.tmp", checkpointing into "current/", then moving "lastcheckpoint.tmp" back to "previous.checkpoint". The idea here was so that there would always be one directory with a valid set of storage files.
> In the HDFS-1073 design, this complicated dance isn't necessary. If a checkpoint fails, we can just rm that single fsimage_N.ckpt file and still be left with a valid storage directory.
> So, we can just let the 2NN keep a single current/ dir around for all checkpoints and eliminate the complexity of the dance.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira