[ https://issues.apache.org/jira/browse/HDFS-7930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14360974#comment-14360974 ]
Konstantin Shvachko commented on HDFS-7930: ------------------------------------------- I saw it with truncate in HDFS-7886, [described in this comment|https://issues.apache.org/jira/browse/HDFS-7886?focusedCommentId=14360903&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14360903]. But it can also happen with a regular block recovery, particularly when DNs are restarting during the recovery. If recovery is started for a UC-block, which already has locations from live DNs, then recovery may succeed only for some of those locations, because the others have e.g. a different length. But {{commitBlockSynchronization()}} will not remove the unconfirmed locations. The locations will be invalidated by the next block report and then replicated correctly, but until then reads may see different data or fail. Will post a failing test once HDFS-7886 is in. Marked it is a blocker for 2.7.0. Feel free to unmark if it is not. > commitBlockSynchronization() does not remove locations, which were not > confirmed > -------------------------------------------------------------------------------- > > 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 > Priority: Blocker > > 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)