hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Konstantin Shvachko (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-7930) commitBlockSynchronization() does not remove locations
Date Tue, 17 Mar 2015 19:11:39 GMT

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

Konstantin Shvachko commented on HDFS-7930:
-------------------------------------------

Looks good now. One last thing is that we should add a logging message in {{markBlockReplicasAsCorrupt()}}
reporting which locations are being marked as corrupt. We can do it on the info level. This
will help finding problems, if there are any.
Also, the test failure is related to the new code. The very first {{checkBlockRecovery()}}
times out. I did not look deep, but it could be because we only have 3 DNs. One replica out
of three is corrupt, but there are no more targets to replicate it before the corrupt replica
can be removed. The log message would have helped.

> commitBlockSynchronization() does not remove locations
> ------------------------------------------------------
>
>                 Key: HDFS-7930
>                 URL: https://issues.apache.org/jira/browse/HDFS-7930
>             Project: Hadoop HDFS
>          Issue Type: Bug
>          Components: namenode
>    Affects Versions: 2.7.0
>            Reporter: Konstantin Shvachko
>            Assignee: Yi Liu
>            Priority: Blocker
>         Attachments: HDFS-7930.001.patch, HDFS-7930.002.patch
>
>
> When {{commitBlockSynchronization()}} has less {{newTargets}} than in the original block
it does not remove unconfirmed locations. This results in that the the block stores locations
of different lengths or genStamp (corrupt).



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

Mime
View raw message