hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Wang (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-10530) BlockManager reconstruction work scheduling should correctly adhere to EC block placement policy
Date Fri, 10 Mar 2017 23:57:04 GMT

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

Andrew Wang commented on HDFS-10530:

Nice investigation Manoj. This relates to a long-standing HDFS supportability issue, where
the only way to fix mis-replicated blocks was to setrep the cluster to 4 then back to 3.

I think the priority thus is to have some way for admins to triggering the big scan. When
I looked earlier, fsck looked like a good place to hook in since it runs on the server side.
Since this patch is pretty self-contained, maybe we can pursue the manual triggering as a
separate JIRA.

As a follow-on, it'd be nice to find some way of fixing these up in the background automatically.
One idea I had is to do it during FBR processing. We want to be careful not to require this
on the fast-path though since FBR processing is already expensive, possibly by using your
ideas regarding tracking topology changes.

Other non-FBR ideas would also be quite welcome, since it duplicates work and it takes a really
long time for all DNs to FBR. Anything that can incrementally iterate the block map would

I think it's also fair to handle some of this in a follow-on JIRA.

> BlockManager reconstruction work scheduling should correctly adhere to EC block placement
> ------------------------------------------------------------------------------------------------
>                 Key: HDFS-10530
>                 URL: https://issues.apache.org/jira/browse/HDFS-10530
>             Project: Hadoop HDFS
>          Issue Type: Sub-task
>          Components: namenode
>            Reporter: Rui Gao
>            Assignee: Rui Gao
>              Labels: hdfs-ec-3.0-nice-to-have
>         Attachments: HDFS-10530.1.patch, HDFS-10530.2.patch, HDFS-10530.3.patch
> This issue was found by [~tfukudom].
> Under RS-DEFAULT-6-3-64k EC policy, 
> 1. Create an EC file, the file was witten to all the 5 racks( 2 dns for each) of the
> 2. Reconstruction work would be scheduled if the 6th rack is added. 
> 3. While adding the 7th rack or more racks will not trigger reconstruction work. 
> Based on default EC block placement policy defined in “BlockPlacementPolicyRackFaultTolerant.java”,
EC file should be able to be scheduled to distribute to 9 racks if possible.
> In *BlockManager#isPlacementPolicySatisfied(BlockInfo storedBlock)* , *numReplicas* of
striped blocks might should be *getRealTotalBlockNum()*, instead of *getRealDataBlockNum()*.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail: hdfs-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-help@hadoop.apache.org

View raw message