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 58CA9108CF for ; Thu, 3 Oct 2013 13:59:02 +0000 (UTC) Received: (qmail 85645 invoked by uid 500); 3 Oct 2013 13:58:58 -0000 Delivered-To: apmail-hadoop-common-user-archive@hadoop.apache.org Received: (qmail 85486 invoked by uid 500); 3 Oct 2013 13:58:58 -0000 Mailing-List: contact common-user-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: common-user@hadoop.apache.org Delivered-To: mailing list common-user@hadoop.apache.org Received: (qmail 85474 invoked by uid 500); 3 Oct 2013 13:58:56 -0000 Delivered-To: apmail-hadoop-core-user@hadoop.apache.org Received: (qmail 85470 invoked by uid 500); 3 Oct 2013 13:58:56 -0000 Delivered-To: apmail-lucene-hadoop-user@lucene.apache.org Received: (qmail 85467 invoked by uid 99); 3 Oct 2013 13:58:56 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 03 Oct 2013 13:58:56 +0000 X-ASF-Spam-Status: No, hits=2.3 required=5.0 tests=SPF_SOFTFAIL,URI_HEX X-Spam-Check-By: apache.org Received-SPF: softfail (nike.apache.org: transitioning domain of marc.sturlese@gmail.com does not designate 216.139.236.26 as permitted sender) Received: from [216.139.236.26] (HELO sam.nabble.com) (216.139.236.26) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 03 Oct 2013 13:58:50 +0000 Received: from ben.nabble.com ([192.168.236.152]) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1VRjQD-0002aN-Uf for hadoop-user@lucene.apache.org; Thu, 03 Oct 2013 06:58:29 -0700 Date: Thu, 3 Oct 2013 06:58:29 -0700 (PDT) From: Marc Sturlese To: hadoop-user@lucene.apache.org Message-ID: <1380808709937-4093337.post@n3.nabble.com> In-Reply-To: References: <1377157312625-4086029.post@n3.nabble.com> <1377160196643-4086038.post@n3.nabble.com> <1377163213765-4086049.post@n3.nabble.com> <329538686.35584896.1377232187382.JavaMail.root@vmware.com> <1380786725782-4093270.post@n3.nabble.com> Subject: Re: rack awarness unexpected behaviour MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Doing that will balance the block writing but I think here you loose the concept of physical rack awareness. Let's say you have 2 physical racks, one with 2 servers and one with 4. If you artificially tell hadoop that one rack has 3 servers and the other 3 you are loosing the concept of rack awareness. You're not guaranteeing that each physical rack contains at least a replica of each block. So if you have 2 racks with different number of servers, it's not possible to do proper rack awareness without filling the disks of the rack with less servers first. Am I right or am I missing something? -- View this message in context: http://lucene.472066.n3.nabble.com/rack-awareness-unexpected-behaviour-tp4086029p4093337.html Sent from the Hadoop lucene-users mailing list archive at Nabble.com.