hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xiaoyu Yao (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-9083) Replication violates block placement policy.
Date Thu, 03 Dec 2015 07:33:11 GMT

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

Xiaoyu Yao commented on HDFS-9083:
----------------------------------

Thanks [~brahmareddy] for the explanation. That helps to understand the issue.
Is this fixed in 2.7.x branches such as branch-2.7.1 or branch-2.7.2? If not, we need a separate
ticket for the unit test fix.

> Replication violates block placement policy.
> --------------------------------------------
>
>                 Key: HDFS-9083
>                 URL: https://issues.apache.org/jira/browse/HDFS-9083
>             Project: Hadoop HDFS
>          Issue Type: Bug
>          Components: namenode
>    Affects Versions: 2.6.0
>            Reporter: Rushabh S Shah
>            Assignee: Rushabh S Shah
>            Priority: Blocker
>             Fix For: 2.7.2, 2.6.3
>
>         Attachments: HDFS-9083-branch-2.6.patch, HDFS-9083-branch-2.7.patch
>
>
> Recently we are noticing many cases in which all the replica of the block are residing
on the same rack.
> During the block creation, the block placement policy was honored.
> But after node failure event in some specific manner, the block ends up in such state.
> On investigating more I found out that BlockManager#blockHasEnoughRacks is dependent
on the config (net.topology.script.file.name)
> {noformat}
>  if (!this.shouldCheckForEnoughRacks) {
>       return true;
>     }
> {noformat}
> We specify DNSToSwitchMapping implementation (our own custom implementation) via net.topology.node.switch.mapping.impl
and no longer use net.topology.script.file.name config.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message