Return-Path: 
 <hdfs-dev-return-2281-apmail-hadoop-hdfs-dev-archive=hadoop.apache.org@hadoop.apache.org>
Delivered-To: apmail-hadoop-hdfs-dev-archive@minotaur.apache.org
Received: (qmail 56481 invoked from network); 24 Feb 2011 22:43:03 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3)
  by minotaur.apache.org with SMTP; 24 Feb 2011 22:43:03 -0000
Received: (qmail 83254 invoked by uid 500); 24 Feb 2011 22:43:02 -0000
Delivered-To: apmail-hadoop-hdfs-dev-archive@hadoop.apache.org
Received: (qmail 82997 invoked by uid 500); 24 Feb 2011 22:43:02 -0000
Mailing-List: contact hdfs-dev-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:hdfs-dev-help@hadoop.apache.org>
List-Unsubscribe: <mailto:hdfs-dev-unsubscribe@hadoop.apache.org>
List-Post: <mailto:hdfs-dev@hadoop.apache.org>
List-Id: <hdfs-dev.hadoop.apache.org>
Reply-To: hdfs-dev@hadoop.apache.org
Delivered-To: mailing list hdfs-dev@hadoop.apache.org
Received: (qmail 82980 invoked by uid 99); 24 Feb 2011 22:43:01 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 24 Feb 2011 22:43:01 +0000
X-ASF-Spam-Status: No, hits=-2000.0 required=5.0
	tests=ALL_TRUSTED,T_RP_MATCHES_RCVD
X-Spam-Check-By: apache.org
Received: from [140.211.11.116] (HELO hel.zones.apache.org) (140.211.11.116)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 24 Feb 2011 22:42:59 +0000
Received: from hel.zones.apache.org (hel.zones.apache.org [140.211.11.116])
	by hel.zones.apache.org (Postfix) with ESMTP id B40801B5B0B
	for <hdfs-dev@hadoop.apache.org>; Thu, 24 Feb 2011 22:42:38 +0000 (UTC)
Date: Thu, 24 Feb 2011 22:42:38 +0000 (UTC)
From: "Tanping Wang (JIRA)" <jira@apache.org>
To: hdfs-dev@hadoop.apache.org
Message-ID: 
 <31323148.14749.1298587358734.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] Created: (HDFS-1648) Federation: Properly release
 in_use.lock created in BlockPoolStorage
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394
X-Virus-Checked: Checked by ClamAV on apache.org

Federation: Properly release in_use.lock created in BlockPoolStorage 
---------------------------------------------------------------------

                 Key: HDFS-1648
                 URL: https://issues.apache.org/jira/browse/HDFS-1648
             Project: Hadoop HDFS
          Issue Type: Bug
          Components: data-node
    Affects Versions: Federation Branch
            Reporter: Tanping Wang
            Assignee: Tanping Wang
             Fix For: Federation Branch


StorageDirectory locks in_use.lock file, when analyzeStorage() method is called during
initialization. 

Since BlockPoolStorage uses this method, an in_use.lock file is created and locked under BlockPool directory
<StorageDirectory>/current/bpid/. This lock is not released when datanode shutsdown. Restarting datanode without
formatting it results in datanode failure to acquire in_use.lock and hence failure to restart.

in_use.lock file that currently exists in <StorageDirectory> (at the datanode level) is sufficient to prevent two
instances of datanodes running on the same node. There is no need for such a lock in block pool directories.

Change is needed so that BlockPoolStorage can disable locking when it creates it's StorageDirectory.


-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira