Return-Path: Delivered-To: apmail-lucene-hadoop-dev-archive@locus.apache.org Received: (qmail 87669 invoked from network); 28 Mar 2006 18:18:17 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 28 Mar 2006 18:18:17 -0000 Received: (qmail 26264 invoked by uid 500); 28 Mar 2006 18:18:17 -0000 Delivered-To: apmail-lucene-hadoop-dev-archive@lucene.apache.org Received: (qmail 26247 invoked by uid 500); 28 Mar 2006 18:18:17 -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 26238 invoked by uid 99); 28 Mar 2006 18:18:17 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 28 Mar 2006 10:18:17 -0800 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received: from [192.87.106.226] (HELO ajax.apache.org) (192.87.106.226) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 28 Mar 2006 10:18:16 -0800 Received: from ajax (localhost.localdomain [127.0.0.1]) by ajax.apache.org (Postfix) with ESMTP id A055AD49FF for ; Tue, 28 Mar 2006 19:17:55 +0100 (BST) Message-ID: <1904146098.1143569875653.JavaMail.jira@ajax> Date: Tue, 28 Mar 2006 19:17:55 +0100 (BST) From: "Doug Cutting (JIRA)" To: hadoop-dev@lucene.apache.org Subject: [jira] Resolved: (HADOOP-19) Datanode corruption MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N [ http://issues.apache.org/jira/browse/HADOOP-19?page=all ] Doug Cutting resolved HADOOP-19: -------------------------------- Resolution: Fixed I added a format command to namenode. Now one must run 'bin/hadoop namenode -format' whenever a new dfs.data.dir is configured. A misconfigured namenode will thus no longer create a new empty filesystem and then tell all datanodes to discard their blocks. > Datanode corruption > ------------------- > > Key: HADOOP-19 > URL: http://issues.apache.org/jira/browse/HADOOP-19 > Project: Hadoop > Type: Bug > Components: dfs > Versions: 0.1 > Reporter: Rod Taylor > Assignee: Doug Cutting > Priority: Critical > Fix For: 0.1 > > Our admins accidentally started a second nutch datanode pointing to the same directories as one already running (same machine) which in turn caused the entire contents of the datanode to go disappear. > This happened because the blocking was based on the username (since fixed in our start scripts) and it was started as two different users. > The ndfs.name.dir and ndfs.data.dir directories were both completely devoid of content, where they had about 150GB not all that much earlier. > I think the solution is improved interlocking within the data directory itself (file locked with flock or something similar). -- 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