[
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)
