Mailing-List: contact hadoop-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hadoop-dev@lucene.apache.org
Message-ID: <877304523.1139251980410.JavaMail.jira@ajax.apache.org>
Date: Mon, 6 Feb 2006 19:53:00 +0100 (CET)
From: "Doug Cutting (JIRA)" <jira@apache.org>
To: hadoop-dev@lucene.apache.org
Subject: [jira] Updated: (HADOOP-19) Datanode corruption
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

     [ http://issues.apache.org/jira/browse/HADOOP-19?page=all ]

Doug Cutting updated HADOOP-19:
-------------------------------

    Component: dfs

> Datanode corruption
> -------------------
>
>          Key: HADOOP-19
>          URL: http://issues.apache.org/jira/browse/HADOOP-19
>      Project: Hadoop
>         Type: Bug
>   Components: dfs
>     Reporter: Rod Taylor
>     Priority: Critical

>
> 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