hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Konstantin Shvachko (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HADOOP-227) Namespace check pointing is not performed until the namenode restarts.
Date Fri, 15 Dec 2006 01:15:24 GMT
    [ http://issues.apache.org/jira/browse/HADOOP-227?page=comments#action_12458650 ] 
Konstantin Shvachko commented on HADOOP-227:

>    * fs.checkpoint.period : Time (in seconds) between two checkpoints.
This is the maximal time between the checkpoints, right?

We should introduce new NamenodeProtocol for primary to secondary name-node communication.

I'd go in the other direction: the primary node checks the edits log size each time it adds
an entry.
When it reaches the checkpoint.size or if the checkpoint was not done longer than checkpoint.period
the primary rolls the edits log and sends a command to the secondary node to create a new

I think we should think about supporting multiple secondary nodes at least at the design stage.
In that case we will need to further propagate the checkpoints.
Or do we just write the latest image into hdfs?

> Namespace check pointing is not performed until the namenode restarts.
> ----------------------------------------------------------------------
>                 Key: HADOOP-227
>                 URL: http://issues.apache.org/jira/browse/HADOOP-227
>             Project: Hadoop
>          Issue Type: Bug
>          Components: dfs
>    Affects Versions: 0.2.0
>            Reporter: Konstantin Shvachko
>         Assigned To: dhruba borthakur
>         Attachments: patch-async-checkpoints-0.9.0, patch-async-checkpoints-0.9.0, patch-async-checkpoints-0.9.0
> In current implementation when the name node starts, it reads its image file, then
> the edits file, and then saves the updated image back into the image file.
> The image file is never updated after that.
> In order to provide the system reliability reliability the namespace information should
> be check pointed periodically, and the edits file should be kept relatively small.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message