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

Jitendra Nath Pandey commented on HDFS-15:
------------------------------------------

  If we go with only one list,  add, remove, update, getPriority methods in  
UnderReplicatedBlocks.java, will need to have another argument to pass the 
numberOfRacks or a boolean to denote insufficient racks. And these methods will 
change to take into account the rack policy. I agree, in that case we should 
rename this class.
  Also, since the blocks with insufficient racks need some special treatment 
(e.g. don't schedule replication if target happens to be on same rack), we 
would need to have checks on priority of the block in BlockManager, if we put 
them in the same queue.
  Ofcourse, if we have different lists, we have to iterate over two lists when 
we process these blocks to schedule replication.

 Apart from these differences, the two approaches are similar in effect. Please 
recommend.

> All replicas of a block end up on only 1 rack
> ---------------------------------------------
>
>                 Key: HDFS-15
>                 URL: https://issues.apache.org/jira/browse/HDFS-15
>             Project: Hadoop HDFS
>          Issue Type: Bug
>            Reporter: Hairong Kuang
>            Assignee: Jitendra Nath Pandey
>            Priority: Critical
>         Attachments: HDFS-15.patch
>
>
> HDFS replicas placement strategy guarantees that the replicas of a block 
> exist on at least two racks when its replication factor is greater than one. 
> But fsck still reports that the replicas of some blocks  end up on one rack.
> The cause of the problem is that decommission and corruption handling only 
> check the block's replication factor but not the rack requirement. When an 
> over-replicated block loses a replica due to decomission, corruption, or 
> heartbeat lost, namenode does not take any action to guarantee that remaining 
> replicas are on different racks.
>  

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to