Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id C64A5200BA3 for ; Thu, 6 Oct 2016 02:57:23 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id C4C9F160AEA; Thu, 6 Oct 2016 00:57:23 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 0B692160ADE for ; Thu, 6 Oct 2016 02:57:22 +0200 (CEST) Received: (qmail 81804 invoked by uid 500); 6 Oct 2016 00:57:22 -0000 Mailing-List: contact hdfs-issues-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list hdfs-issues@hadoop.apache.org Received: (qmail 81780 invoked by uid 99); 6 Oct 2016 00:57:21 -0000 Received: from arcas.apache.org (HELO arcas) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 06 Oct 2016 00:57:21 +0000 Received: from arcas.apache.org (localhost [127.0.0.1]) by arcas (Postfix) with ESMTP id DB1872C002D for ; Thu, 6 Oct 2016 00:57:21 +0000 (UTC) Date: Thu, 6 Oct 2016 00:57:21 +0000 (UTC) From: "Jing Zhao (JIRA)" To: hdfs-issues@hadoop.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Updated] (HDFS-10968) BlockManager#isNewRack should consider decommissioning nodes MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 archived-at: Thu, 06 Oct 2016 00:57:24 -0000 [ https://issues.apache.org/jira/browse/HDFS-10968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jing Zhao updated HDFS-10968: ----------------------------- Status: Patch Available (was: Open) > BlockManager#isNewRack should consider decommissioning nodes > ------------------------------------------------------------ > > Key: HDFS-10968 > URL: https://issues.apache.org/jira/browse/HDFS-10968 > Project: Hadoop HDFS > Issue Type: Sub-task > Components: erasure-coding, namenode > Affects Versions: 3.0.0-alpha1 > Reporter: Jing Zhao > Assignee: Jing Zhao > Attachments: HDFS-10968.000.patch > > > For an EC block, it is possible we have enough internal blocks but without enough racks. The current reconstruction code calls {{BlockManager#isNewRack}} to check if the target node can increase the total rack number for the case, which compares the target node's rack with source node racks: > {code} > for (DatanodeDescriptor src : srcs) { > if (src.getNetworkLocation().equals(target.getNetworkLocation())) { > return false; > } > } > {code} > However here the {{srcs}} may include a decommissioning node, in which case we should allow the target node to be in the same rack with it. > For e.g., suppose we have 11 nodes: h1 ~ h11, which are located in racks r1, r1, r2, r2, r3, r3, r4, r4, r5, r5, r6, respectively. In case that an EC block has 9 live internal blocks on (h1~h8 + h11), and one internal block on h9 which is to be decommissioned. The current code will not choose h10 for reconstruction because isNewRack thinks h10 is on the same rack with h9. -- This message was sent by Atlassian JIRA (v6.3.4#6332) --------------------------------------------------------------------- To unsubscribe, e-mail: hdfs-issues-unsubscribe@hadoop.apache.org For additional commands, e-mail: hdfs-issues-help@hadoop.apache.org