[
https://issues.apache.org/jira/browse/HDFS-7930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14362924#comment-14362924
]
Yi Liu commented on HDFS-7930:
------------------------------
[~shv], you are right.
After block recovery, if {{commitBlockSynchronization}} has less {{newTargets}}
than in the original block, we should mark replicas of that block *corrupt* on
those DNs (Let's call them temporarily-down-DNs) who have not participated in
block recovery (maybe shutdown), since the genStamp of the block on those
temporarily-down-DNs should be old. While current implementation doesn't do
this. Unless those temporarily-down-DNs are restarted again and NN receives
block report from them, NN will mark replicas of that block *corrupt*.
This results in that user could get blocks with corrupt locations of different
lengths or genStamp as you said, it's an critical issue.
As I, you and Plamen discussed in HDFS-7886, in those tests, we rely on block
report indeed happens after DN restarted, the reason is that NN will mark the
replicas on bad DN corrupt and truncated block will be replicated to the bad DN
after it restarted. After this fix, {{commitBlockSynchronization}} can also
update locations of block replicas.
> 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
>
>
> 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)
