Mailing-List: contact common-dev-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: common-dev@hadoop.apache.org
Date: Thu, 29 Dec 2011 05:50:30 +0000 (UTC)
From: "Harsh J (Resolved) (JIRA)" <jira@apache.org>
To: common-dev@hadoop.apache.org
Message-ID: 
 <1838008563.50555.1325137830989.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Resolved] (HADOOP-3211) Utility to enforce current
 replication policy on already exitsting blocks
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/HADOOP-3211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Harsh J resolved HADOOP-3211.
-----------------------------

    Resolution: Not A Problem

The balancer does this today. The BlockManager and its services do not, however.
                
> Utility to enforce current replication policy on already exitsting blocks
> -------------------------------------------------------------------------
>
>                 Key: HADOOP-3211
>                 URL: https://issues.apache.org/jira/browse/HADOOP-3211
>             Project: Hadoop Common
>          Issue Type: New Feature
>            Reporter: Robert Chansler
>
> If the replica placement policy changes, or if the cluster topology changes, existing block replicas will not be deliberately moved to implement the new policy or to reflect the new topology. The re-replicator and the re-balancer always implement the current policy, but a healthy block may never attract the attention of either of those facilities. 
> In practice, all replicas of a block have been found within a single rack (as allowed by the previous _random rack_ placement policy. The {{fsck}} facility reports such examples.
> The re-placer utility could follow the model of the re-balancer. Or even be part of the re-balancer.
> An alternative implementation would scan the {{fsck}} report for curious blocks, and rename a replica block file on the data node, so as to hide it. The re-replicator would be expected to create a new replica properly placed. (This is a fix up that any administrator could implement.)
> (1761414)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira