[ 
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 checkpoint.

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

        

Reply via email to