[ https://issues.apache.org/jira/browse/HDFS-15422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17287194#comment-17287194 ]
Stephen O'Donnell commented on HDFS-15422: ------------------------------------------ We have had a report of something that sounds very like this problem. Appended blocks, failover and the blocks are marked corrupt. They are still readable etc. I suspect if we fail back over and restart the new SBNN it will clear it, but I am waiting to confirm that. This is on Cloudera CDP 7.x, which is a heavily patched 3.1 build. It looks like this problem is still there on trunk. From earlier comments, it sounds like a unit test for this is very difficult, so I will post a trunk patch with the small change [~kihwal] suggested and see what Yetus says. > Reported IBR is partially replaced with stored info when queuing. > ----------------------------------------------------------------- > > Key: HDFS-15422 > URL: https://issues.apache.org/jira/browse/HDFS-15422 > Project: Hadoop HDFS > Issue Type: Bug > Components: namenode > Reporter: Kihwal Lee > Priority: Critical > Attachments: HDFS-15422-branch-2.10.001.patch > > > When queueing an IBR (incremental block report) on a standby namenode, some > of the reported information is being replaced with the existing stored > information. This can lead to false block corruption. > We had a namenode, after transitioning to active, started reporting missing > blocks with "SIZE_MISMATCH" as corrupt reason. These were blocks that were > appended and the sizes were actually correct on the datanodes. Upon further > investigation, it was determined that the namenode was queueing IBRs with > altered information. > Although it sounds bad, I am not making it blocker -- This message was sent by Atlassian Jira (v8.3.4#803005) --------------------------------------------------------------------- To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org