Mailing-List: contact hdfs-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hdfs-issues@hadoop.apache.org
Date: Wed, 18 Dec 2013 19:25:08 +0000 (UTC)
From: "Arpit Agarwal (JIRA)" <jira@apache.org>
To: hdfs-issues@hadoop.apache.org
Message-ID: <JIRA.12684358.1386884295728.59464.1387394708880@arcas>
In-Reply-To: <JIRA.12684358.1386884295728@arcas>
References: <JIRA.12684358.1386884295728@arcas>
Subject: [jira] [Commented] (HDFS-5662) Can't decommission a DataNode due to
 file's replication factor larger than the rest of the cluster size
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/HDFS-5662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13852055#comment-13852055 ] 

Arpit Agarwal commented on HDFS-5662:
-------------------------------------

+1 for the updated patch.

> Can't decommission a DataNode due to file's replication factor larger than the rest of the cluster size
> -------------------------------------------------------------------------------------------------------
>
>                 Key: HDFS-5662
>                 URL: https://issues.apache.org/jira/browse/HDFS-5662
>             Project: Hadoop HDFS
>          Issue Type: Bug
>          Components: namenode
>            Reporter: Brandon Li
>            Assignee: Brandon Li
>         Attachments: HDFS-5662.001.patch, HDFS-5662.002.patch
>
>
> A datanode can't be decommissioned if it has replica that belongs to a file with a replication factor larger than the rest of the cluster size.
> One way to fix this is to have some kind of minimum replication factor setting and thus any datanode can be decommissioned regardless of the largest replication factor it's related to. 


--
This message was sent by Atlassian JIRA
(v6.1.4#6159)