hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tsz Wo Nicholas Sze (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-8540) Mover should exit with NO_MOVE_BLOCK if no block can be moved
Date Mon, 08 Jun 2015 19:27:00 GMT

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

Tsz Wo Nicholas Sze commented on HDFS-8540:
-------------------------------------------

Yes, NO_MOVE_BLOCK means that "No block can be moved".  If some blocks can be moved in current
iteration, space may be freed up so that the blocks failed to move may possibly be moved in
the next iteration.

> Mover should exit with NO_MOVE_BLOCK if no block can be moved
> -------------------------------------------------------------
>
>                 Key: HDFS-8540
>                 URL: https://issues.apache.org/jira/browse/HDFS-8540
>             Project: Hadoop HDFS
>          Issue Type: Sub-task
>          Components: balancer & mover
>            Reporter: Tsz Wo Nicholas Sze
>            Assignee: surendra singh lilhore
>         Attachments: HDFS-8540.patch
>
>
> When there are files not satisfying their storage policy and no move is possible, Mover
exits with SUCCESS.  It should exit with NO_MOVE_BLOCK.
> The bug seems in the following code.  When StorageTypeDiff is not empty and scheduleMoves4Block
return false, it does not update hasRemaining.  Also, there is no indication of "No block
can be moved" for the entire iteration.
> {code}
> //Mover.processFile(..)
>         if (!diff.removeOverlap(true)) {
>           if (scheduleMoves4Block(diff, lb, ecSchema)) {
>             hasRemaining |= (diff.existing.size() > 1 &&
>                 diff.expected.size() > 1);
>           }
>         }
> {code}



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

Mime
View raw message