hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rakesh R (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-11164) Mover should avoid unnecessary retries if the block is pinned
Date Mon, 12 Dec 2016 18:46:58 GMT

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

Rakesh R commented on HDFS-11164:
---------------------------------

Thanks a lot [~surendrasingh] for the test feedback.

IMHO, this information is not required to place in NN and the first failure is OK considering
the additional cost of maintaining the block pinned info at the NN server and again this has
to be synced up during DN restart via block report etc. Also, I've gone through the HDFS-6133
comments and [I could see some interesting discussion about the design of block pinning|https://issues.apache.org/jira/browse/HDFS-6133?focusedCommentId=13984113&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13984113].
Do you agree to go ahead with the proposed approach in the patch?

> Mover should avoid unnecessary retries if the block is pinned
> -------------------------------------------------------------
>
>                 Key: HDFS-11164
>                 URL: https://issues.apache.org/jira/browse/HDFS-11164
>             Project: Hadoop HDFS
>          Issue Type: Bug
>          Components: balancer & mover
>            Reporter: Rakesh R
>            Assignee: Rakesh R
>         Attachments: HDFS-11164-00.patch, HDFS-11164-01.patch, HDFS-11164-02.patch, HDFS-11164-03.patch
>
>
> When mover is trying to move a pinned block to another datanode, it will internally hits
the following IOException and mark the block movement as {{failure}}. Since the Mover has
{{dfs.mover.retry.max.attempts}} configs, it will continue moving this block until it reaches
{{retryMaxAttempts}}. If the block movement failure(s) are only due to block pinning, then
retry is unnecessary. The idea of this jira is to avoid retry attempts of pinned blocks as
they won't be able to move to a different node. 
> {code}
> 2016-11-22 10:56:10,537 WARN org.apache.hadoop.hdfs.server.balancer.Dispatcher: Failed
to move blk_1073741825_1001 with size=52 from 127.0.0.1:19501:DISK to 127.0.0.1:19758:ARCHIVE
through 127.0.0.1:19501
> java.io.IOException: Got error, status=ERROR, status message opReplaceBlock BP-1772076264-10.252.146.200-1479792322960:blk_1073741825_1001
received exception java.io.IOException: Got error, status=ERROR, status message Not able to
copy block 1073741825 to /127.0.0.1:19826 because it's pinned , copy block BP-1772076264-10.252.146.200-1479792322960:blk_1073741825_1001
from /127.0.0.1:19501, reportedBlock move is failed
> 	at org.apache.hadoop.hdfs.protocol.datatransfer.DataTransferProtoUtil.checkBlockOpStatus(DataTransferProtoUtil.java:118)
> 	at org.apache.hadoop.hdfs.server.balancer.Dispatcher$PendingMove.receiveResponse(Dispatcher.java:417)
> 	at org.apache.hadoop.hdfs.server.balancer.Dispatcher$PendingMove.dispatch(Dispatcher.java:358)
> 	at org.apache.hadoop.hdfs.server.balancer.Dispatcher$PendingMove.access$5(Dispatcher.java:322)
> 	at org.apache.hadoop.hdfs.server.balancer.Dispatcher$1.run(Dispatcher.java:1075)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.run(Thread.java:745)
> {code}



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

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


Mime
View raw message