Return-Path: Delivered-To: apmail-lucene-hadoop-dev-archive@locus.apache.org Received: (qmail 22021 invoked from network); 26 Jul 2007 20:58:25 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 26 Jul 2007 20:58:25 -0000 Received: (qmail 60123 invoked by uid 500); 26 Jul 2007 20:58:25 -0000 Delivered-To: apmail-lucene-hadoop-dev-archive@lucene.apache.org Received: (qmail 60096 invoked by uid 500); 26 Jul 2007 20:58:25 -0000 Mailing-List: contact hadoop-dev-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: hadoop-dev@lucene.apache.org Delivered-To: mailing list hadoop-dev@lucene.apache.org Received: (qmail 60087 invoked by uid 99); 26 Jul 2007 20:58:25 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 26 Jul 2007 13:58:25 -0700 X-ASF-Spam-Status: No, hits=-100.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.4] (HELO brutus.apache.org) (140.211.11.4) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 26 Jul 2007 13:58:24 -0700 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id EBAF87141F0 for ; Thu, 26 Jul 2007 13:58:03 -0700 (PDT) Message-ID: <21102563.1185483483958.JavaMail.jira@brutus> Date: Thu, 26 Jul 2007 13:58:03 -0700 (PDT) From: "Stu Hood (JIRA)" To: hadoop-dev@lucene.apache.org Subject: [jira] Commented: (HADOOP-1652) Rebalance data blocks when new data nodes added or data nodes become full In-Reply-To: <24604182.1185389251651.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/HADOOP-1652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12515859 ] Stu Hood commented on HADOOP-1652: ---------------------------------- {quote} ...among which we should favor data nodes that are on the same rack as the target data node. {quote} This is a tradeoff though... one of the reasons for recording what racks blocks are on is to prevent putting "all of your eggs in one basket" so to speak (See the middle paragraph of http://lucene.apache.org/hadoop/hdfs_design.html#Data+Replication ). > Rebalance data blocks when new data nodes added or data nodes become full > ------------------------------------------------------------------------- > > Key: HADOOP-1652 > URL: https://issues.apache.org/jira/browse/HADOOP-1652 > Project: Hadoop > Issue Type: New Feature > Components: dfs > Affects Versions: 0.13.0 > Reporter: Hairong Kuang > Assignee: Hairong Kuang > Fix For: 0.15.0 > > > When a new data node joins hdfs cluster, it does not hold much data. So any map task assigned to the machine most likely does not read local data, thus increasing the use of network bandwidth. On the other hand, when some data nodes become full, new data blocks are placed on only non-full data nodes, thus reducing their read parallelism. > This jira aims to find an approach to redistribute data blocks when imbalance occurs in the cluster. An solution should meet the following requirements: > 1. It maintains data availablility guranteens in the sense that rebalancing does not reduce the number of replicas that a block has or the number of racks that the block resides. > 2. An adminstrator should be able to invoke and interrupt rebalancing from a command line. > 3. Rebalancing should be throttled so that rebalancing does not cause a namenode to be too busy to serve any incoming request or saturate the network. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.