Return-Path: X-Original-To: apmail-hadoop-common-user-archive@www.apache.org Delivered-To: apmail-hadoop-common-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id A33371131E for ; Tue, 20 May 2014 07:39:58 +0000 (UTC) Received: (qmail 48536 invoked by uid 500); 20 May 2014 07:39:54 -0000 Delivered-To: apmail-hadoop-common-user-archive@hadoop.apache.org Received: (qmail 48431 invoked by uid 500); 20 May 2014 07:39:54 -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 48424 invoked by uid 99); 20 May 2014 07:39:54 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 20 May 2014 07:39:54 +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 (athena.apache.org: domain of rajkrrsingh@gmail.com designates 209.85.216.172 as permitted sender) Received: from [209.85.216.172] (HELO mail-qc0-f172.google.com) (209.85.216.172) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 20 May 2014 07:39:50 +0000 Received: by mail-qc0-f172.google.com with SMTP id l6so124643qcy.31 for ; Tue, 20 May 2014 00:39:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=ZUMML4glyT3Nl74m+8VqPM/UjcXRvMW6dFfrR9k3w+k=; b=MhFayG+Tv1ycXl8MP4jVeL7KeUzOVeWr8Q12fOYhImiiyRnWKT3+x8k1T0sK0S3RWc cmSEx2XdHk9tY0/0e6MTyiAr0nb3jpvoiHXx93iSw0VFR78jAg4+cr03N46ES+fZYM4Y Piv3ni56xn1Vcin09dugY473YAlZQ9ugEPuMpQxdcR/3I4qoG6IIbcRbkX+06p/JDJmn R3yy+SroS/WJxGlFBMbdYzV4xtmYc0BENuQPA6rTns0+MoBf2n89d4Y3Ez0W4UHFrE08 3q7z1S4guTFQ1WilAHNyIMTzW9coHnOSoQYsJ3lEeUZzl0VnfW8gwOo0EfAWSBFbQaPr UyrA== X-Received: by 10.140.102.161 with SMTP id w30mr17882020qge.108.1400571570327; Tue, 20 May 2014 00:39:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.82.36 with HTTP; Tue, 20 May 2014 00:39:00 -0700 (PDT) In-Reply-To: References: From: Raj K Singh Date: Tue, 20 May 2014 13:09:00 +0530 Message-ID: Subject: Re: Rack awareness and pipeline write To: user@hadoop.apache.org Content-Type: multipart/alternative; boundary=001a11c16db4ee95ef04f9cffad5 X-Virus-Checked: Checked by ClamAV on apache.org --001a11c16db4ee95ef04f9cffad5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable it's fine two place 2 replica on the local rack's nodes first and then the third replica on the different rack node if the replica count is 3. now consider the scenario for the replication factor 2. if it place these two replica on the same rack, then you can loose all of your replica when the rack goes down. hope it will clear your doubt. :::::::::::::::::::::::::::::::::::::::: Raj K Singh http://in.linkedin.com/in/rajkrrsingh http://www.rajkrrsingh.blogspot.com Mobile Tel: +91 (0)9899821370 On Sun, May 11, 2014 at 8:25 AM, jianan hu wrote: > Hi everyone, > > See HDFS documents, It says "For the common case, when the replication > factor is three, HDFS=E2=80=99s placement policy is to put one replica on= one node > in the local rack, another on a node in a different (remote) rack, and th= e > last on a different node in the same remote rack." > > Assume there are two racks A and B. According to rack awareness, the firs= t > block is put in rack A, and the the other two replicated blocks will be > pushed into rack B. > > However, why not store the first and second replicas in the local rack > (A), and the last in a different remote rack (B)? Both two scenarios have > same network traffic. What's the disadvantage of it? > > Thanks. > > Best Regards, > Jianan > --001a11c16db4ee95ef04f9cffad5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
it's fine two place 2 replica on the local rack's = nodes first and then the third replica on the different rack node if the re= plica count is 3.
= now consider the scenario for the replication factor 2. if it place these t= wo replica on the same rack, then you can loose all of your replica when th= e rack goes down.
= hope it will clear your doubt.

:::::::= :::::::::::::::::::::::::::::::::
Raj K Singh


On Sun, May 11, 2014 at 8:25 AM, jianan = hu <hujianan@gmail.com> wrote:
Hi everyone,

S= ee HDFS documents, It says "For the common case, when the replication = factor is three, HDFS=E2=80=99s placement policy is to put one replica on o= ne node in the local rack, another on a node in a different (remote) rack, = and the last on a different node in the same remote rack."

Assume there are two r= acks A and B. According to rack awareness, the first block is put in rack A= , and the the other two replicated blocks will be pushed into rack B.

However, why not store= the first and second replicas in the local rack (A), and the last in a dif= ferent remote rack (B)? Both two scenarios have same network traffic. What&= #39;s the disadvantage of it?

Thanks.

Best Regards,
Jianan

--001a11c16db4ee95ef04f9cffad5--