Return-Path: X-Original-To: apmail-hadoop-hdfs-user-archive@minotaur.apache.org Delivered-To: apmail-hadoop-hdfs-user-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 21EE410A0E for ; Tue, 2 Jul 2013 06:05:28 +0000 (UTC) Received: (qmail 61272 invoked by uid 500); 2 Jul 2013 06:05:23 -0000 Delivered-To: apmail-hadoop-hdfs-user-archive@hadoop.apache.org Received: (qmail 61171 invoked by uid 500); 2 Jul 2013 06:05:22 -0000 Mailing-List: contact user-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@hadoop.apache.org Delivered-To: mailing list user@hadoop.apache.org Received: (qmail 61164 invoked by uid 99); 2 Jul 2013 06:05:22 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 02 Jul 2013 06:05:22 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of samliuhadoop@gmail.com designates 74.125.83.43 as permitted sender) Received: from [74.125.83.43] (HELO mail-ee0-f43.google.com) (74.125.83.43) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 02 Jul 2013 06:05:16 +0000 Received: by mail-ee0-f43.google.com with SMTP id l10so2441722eei.16 for ; Mon, 01 Jul 2013 23:04:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=SEllq7ZAT7EOZ1qR0u83mIxN+hjLkAMCjaNaa5HKla4=; b=SNZ+FUe9DpYhLd4E8n5+beloVECvX0hk6d5bg7JRXDRe2r/Y2UnwKdKpAO2JUVEOoK lFy1bxV6qPVtLbCYA1pG4krSafrbZ6MxNpyHQcs1DoEDacUm0mUu1RJHg0HClBBUVhuk pYS0Lt9i+A25Bm7xPb060+phKAv8x5aOObe6ZzOlqCaJNVpRx1cd1VtapIpgNoPdNhJx gCfYeAOD1fTK70VNtBsaoLcKM/ZKiPqB0VJPOmVwLMUPxe80aiecvJogcS0mK8xVdZA5 Ezli2XT+njyYH6k51XDIwr+i5Coen0fHv0+SG3iT/UXXnHmU2E2UFsJMYDFHWa71K83w Re8A== MIME-Version: 1.0 X-Received: by 10.14.0.131 with SMTP id 3mr23971089eeb.98.1372745096269; Mon, 01 Jul 2013 23:04:56 -0700 (PDT) Received: by 10.14.223.137 with HTTP; Mon, 1 Jul 2013 23:04:56 -0700 (PDT) In-Reply-To: References: <51C41E24.7030108@mail.ntua.gr> Date: Tue, 2 Jul 2013 14:04:56 +0800 Message-ID: Subject: Re: Hang when add/remove a datanode into/from a 2 datanode cluster From: sam liu To: "user@hadoop.apache.org" Content-Type: multipart/alternative; boundary=047d7b6042bed4af4004e0811f95 X-Virus-Checked: Checked by ClamAV on apache.org --047d7b6042bed4af4004e0811f95 Content-Type: text/plain; charset=ISO-8859-1 Yes, the default replication factor is 3. However, in my case, it's strange: during decommission hangs, I found some block's expected replicas is 3, but the 'dfs.replication' value in hdfs-site.xml of every cluster node is always 2 from the beginning of cluster setup. Below is my steps: 1. Install a Hadoop 1.1.1 cluster, with 2 datanodes: dn1 and dn2. And, in hdfs-site.xml, set the 'dfs.replication' to 2 2. Add node dn3 into the cluster as a new datanode, and did not change the ' dfs.replication' value in hdfs-site.xml and keep it as 2 note: step 2 passed 3. Decommission dn3 from the cluster Expected result: dn3 could be decommissioned successfully Actual result: a). decommission progress hangs and the status always be 'Waiting DataNode status: Decommissioned'. But, if I execute 'hadoop dfs -setrep -R 2 /', the decommission continues and will be completed finally. b). However, if the initial cluster includes >= 3 datanodes, this issue won't be encountered when add/remove another datanode. For example, if I setup a cluster with 3 datanodes, and then I can successfully add the 4th datanode into it, and then also can successfully remove the 4th datanode from the cluster. I doubt it's a bug and plan to open a jira to Hadoop HDFS for this. Any comments? Thanks! 2013/6/21 Harsh J > The dfs.replication is a per-file parameter. If you have a client that > does not use the supplied configs, then its default replication is 3 > and all files it will create (as part of the app or via a job config) > will be with replication factor 3. > > You can do an -lsr to find all files and filter which ones have been > created with a factor of 3 (versus expected config of 2). > > On Fri, Jun 21, 2013 at 3:13 PM, sam liu wrote: > > Hi George, > > > > Actually, in my hdfs-site.xml, I always set 'dfs.replication'to 2. But > still > > encounter this issue. > > > > Thanks! > > > > > > 2013/6/21 George Kousiouris > >> > >> > >> Hi, > >> > >> I think i have faced this before, the problem is that you have the rep > >> factor=3 so it seems to hang because it needs 3 nodes to achieve the > factor > >> (replicas are not created on the same node). If you set the replication > >> factor=2 i think you will not have this issue. So in general you must > make > >> sure that the rep factor is <= to the available datanodes. > >> > >> BR, > >> George > >> > >> > >> On 6/21/2013 12:29 PM, sam liu wrote: > >> > >> Hi, > >> > >> I encountered an issue which hangs the decommission operatoin. Its > steps: > >> 1. Install a Hadoop 1.1.1 cluster, with 2 datanodes: dn1 and dn2. And, > in > >> hdfs-site.xml, set the 'dfs.replication' to 2 > >> 2. Add node dn3 into the cluster as a new datanode, and did not change > the > >> 'dfs.replication' value in hdfs-site.xml and keep it as 2 > >> note: step 2 passed > >> 3. Decommission dn3 from the cluster > >> > >> Expected result: dn3 could be decommissioned successfully > >> > >> Actual result: decommission progress hangs and the status always be > >> 'Waiting DataNode status: Decommissioned' > >> > >> However, if the initial cluster includes >= 3 datanodes, this issue > won't > >> be encountered when add/remove another datanode. > >> > >> Also, after step 2, I noticed that some block's expected replicas is 3, > >> but the 'dfs.replication' value in hdfs-site.xml is always 2! > >> > >> Could anyone pls help provide some triages? > >> > >> Thanks in advance! > >> > >> > >> > >> -- > >> --------------------------- > >> > >> George Kousiouris, PhD > >> Electrical and Computer Engineer > >> Division of Communications, > >> Electronics and Information Engineering > >> School of Electrical and Computer Engineering > >> Tel: +30 210 772 2546 > >> Mobile: +30 6939354121 > >> Fax: +30 210 772 2569 > >> Email: gkousiou@mail.ntua.gr > >> Site: http://users.ntua.gr/gkousiou/ > >> > >> National Technical University of Athens > >> 9 Heroon Polytechniou str., 157 73 Zografou, Athens, Greece > > > > > > > > -- > Harsh J > --047d7b6042bed4af4004e0811f95 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Yes, the default replication factor is 3. However, in= my case, it's strange: during decommission hangs, I found some block&#= 39;s expected replicas is 3, but the 'dfs.replication' value in hdfs-site.xml of every cluste= r node is always 2 from the beginning of cluster setup. Below is my steps:<= br>
1. Install a Hadoop 1.1.1 cluster, with 2 datanodes: dn1 and dn2. And,= in hdfs-site.xml, set the 'dfs.replication' to 2
2. Add node dn3 into the cluster as a new datanode, and did not = change the 'dfs.replicatio= n' value in hdfs-site.xml and keep it as 2
note: step= 2 passed
3. Decommission dn3 from the cluster
Expected result: dn3 could be = decommissioned successfully
Actual result:
a). decommission pr= ogress hangs and the status always be 'Waiting DataNode status: Decommi= ssioned'. But, if I execute 'hadoop dfs -setrep -R 2 /', the de= commission continues and will be completed finally.
b). However, if the initial cluster includes >=3D 3 datanodes, this issu= e won't be encountered when add/remove another datanode. For example, i= f I setup a cluster with 3 datanodes, and then I can successfully add the 4= th datanode into it, and then also can successfully remove the 4th datanode= from the cluster.

I doubt it's a bug and plan to open a jira to Hadoop HDF= S for this. Any comments?

Thanks!


2013/6/21 Harsh J <harsh@= cloudera.com>
The dfs.replication is a per-file parameter.= If you have a client that
does not use the supplied configs, then its default replication is 3
and all files it will create (as part of the app or via a job config)
will be with replication factor 3.

You can do an -lsr to find all files and filter which ones have been
created with a factor of 3 (versus expected config of 2).

On Fri, Jun 21, 2013 at 3:13 PM, sam liu <samliuhadoop@gmail.com> wrote:
> Hi George,
>
> Actually, in my hdfs-site.xml, I always set 'dfs.replication't= o 2. But still
> encounter this issue.
>
> Thanks!
>
>
> 2013/6/21 George Kousiouris <gkousiou@mail.ntua.gr>
>>
>>
>> Hi,
>>
>> I think i have faced this before, the problem is that you have the= rep
>> factor=3D3 so it seems to hang because it needs 3 nodes to achieve= the factor
>> (replicas are not created on the same node). If you set the replic= ation
>> factor=3D2 i think you will not have this issue. So in general you= must make
>> sure that the rep factor is <=3D to the available datanodes. >>
>> BR,
>> George
>>
>>
>> On 6/21/2013 12:29 PM, sam liu wrote:
>>
>> Hi,
>>
>> I encountered an issue which hangs the decommission operatoin. Its= steps:
>> 1. Install a Hadoop 1.1.1 cluster, with 2 datanodes: dn1 and dn2. = And, in
>> hdfs-site.xml, set the 'dfs.replication' to 2
>> 2. Add node dn3 into the cluster as a new datanode, and did not ch= ange the
>> 'dfs.replication' value in hdfs-site.xml and keep it as 2<= br> >> note: step 2 passed
>> 3. Decommission dn3 from the cluster
>>
>> Expected result: dn3 could be decommissioned successfully
>>
>> Actual result: decommission progress hangs and the status always b= e
>> 'Waiting DataNode status: Decommissioned'
>>
>> However, if the initial cluster includes >=3D 3 datanodes, this= issue won't
>> be encountered when add/remove another datanode.
>>
>> Also, after step 2, I noticed that some block's expected repli= cas is 3,
>> but the 'dfs.replication' value in hdfs-site.xml is always= 2!
>>
>> Could anyone pls help provide some triages?
>>
>> Thanks in advance!
>>
>>
>>
>> --
>> ---------------------------
>>
>> George Kousiouris, PhD
>> Electrical and Computer Engineer
>> Division of Communications,
>> Electronics and Information Engineering
>> School of Electrical and Computer Engineering
>> Tel: +30 210 772 2546
>> Mobile: +30 6939354121
>> Fax: +30 210 772 2569
>> Email: gkousiou@mail.ntua= .gr
>> Site: http://users.ntua.gr/gkousiou/
>>
>> National Technical University of Athens
>> 9 Heroon Polytechniou str., 157 73 Zografou, Athens, Greece
>
>



--
Harsh J

--047d7b6042bed4af4004e0811f95--