Return-Path: Delivered-To: apmail-lucene-hadoop-dev-archive@locus.apache.org Received: (qmail 46089 invoked from network); 15 Dec 2006 01:15:46 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 15 Dec 2006 01:15:46 -0000 Received: (qmail 98291 invoked by uid 500); 15 Dec 2006 01:15:53 -0000 Delivered-To: apmail-lucene-hadoop-dev-archive@lucene.apache.org Received: (qmail 98255 invoked by uid 500); 15 Dec 2006 01:15:53 -0000 Mailing-List: contact hadoop-dev-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: hadoop-dev@lucene.apache.org Delivered-To: mailing list hadoop-dev@lucene.apache.org Received: (qmail 98246 invoked by uid 99); 15 Dec 2006 01:15:53 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 14 Dec 2006 17:15:53 -0800 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received: from [140.211.11.4] (HELO brutus.apache.org) (140.211.11.4) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 14 Dec 2006 17:15:44 -0800 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id C11737140D2 for ; Thu, 14 Dec 2006 17:15:24 -0800 (PST) Message-ID: <1932443.1166145324788.JavaMail.jira@brutus> Date: Thu, 14 Dec 2006 17:15:24 -0800 (PST) From: "Konstantin Shvachko (JIRA)" To: hadoop-dev@lucene.apache.org Subject: [jira] Commented: (HADOOP-227) Namespace check pointing is not performed until the namenode restarts. In-Reply-To: <17890828.1147909205885.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org [ 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