[
https://issues.apache.org/jira/browse/HDFS-7930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14364621#comment-14364621
]
Konstantin Shvachko commented on HDFS-7930:
-------------------------------------------
Looks like the right fix. Few suggestions:
# Merge test cases {{testTruncateWithDataNodesRestart()}} and
{{testTruncateWithDataNodesRestart1()}} into one. The latter seems to be a more
detailed case of the former.
# Also you should use {{restartDataNode()}} with {{expireOnNN == true}} now
that HDFS-7886 is in.
# Remove misleading comment in {{FSN.commitBlockSync()}}
{{// There should be no locations in the blockManager till now ....}}
# Few improvements to {{markBlockReplicasAsCorrupt()}}
#- {{excludedStorages}} should be {{newStorages}} or {{committedStorages}}
#- Better keep the parameter declaration on a single line
#- {{toMark}} could be {{isCorrupt}}
#- Just {{else return;}} when the genStamp and the length are the same as the
old ones.
#- Redundant check {{excludedStorages.length > 0}}
> 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)
