[
https://issues.apache.org/jira/browse/HDFS-7065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14134484#comment-14134484
]
Hadoop QA commented on HDFS-7065:
---------------------------------
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12668840/HDFS-7065.patch
against trunk revision 9d4ec97.
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javadoc{color}. There were no new javadoc warning messages.
{color:green}+1 eclipse:eclipse{color}. The patch built with
eclipse:eclipse.
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 2.0.3) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:red}-1 core tests{color}. The test build failed in
hadoop-hdfs-project/hadoop-hdfs
{color:green}+1 contrib tests{color}. The patch passed contrib unit tests.
Test results:
https://builds.apache.org/job/PreCommit-HDFS-Build/8034//testReport/
Console output: https://builds.apache.org/job/PreCommit-HDFS-Build/8034//console
This message is automatically generated.
> Pipeline close recovery race can cause block corruption
> -------------------------------------------------------
>
> Key: HDFS-7065
> URL: https://issues.apache.org/jira/browse/HDFS-7065
> Project: Hadoop HDFS
> Issue Type: Bug
> Affects Versions: 2.5.0
> Reporter: Kihwal Lee
> Priority: Critical
> Attachments: HDFS-7065.patch
>
>
> If multiple pipeline close recoveries are performed against the same block,
> the replica may go corrupt. Here is one case I have observed:
> The client tried to close a block, but the ACK timed out. It excluded the
> first DN and tried pipeline recovery (recoverClose). It too failed and
> another recovery was attempted with only one DN. This took more than usual
> but the client eventually got an ACK and the file was closed successfully.
> Later on the one and only replica was found to be corrupt.
> It turned out the DN was having transient slow disk I/O issue at that time.
> The first recovery was stuck until the second recovery was attempted 30
> seconds later. After few seconds, they both threads started running. The
> second recovery finished first and then the first recovery with an older gen
> stamp finished, turning gen stamp backward.
> There is a sanity check in {{recoverCheck()}}, but since check and modify are
> not synchronized, {{recoverClose()}} is not multi-thread safe.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
