[ https://issues.apache.org/jira/browse/HDFS-10301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15254994#comment-15254994 ]
Konstantin Shvachko commented on HDFS-10301: -------------------------------------------- Colin I ran your unit test and verified that it fails on current code base, but succeeds with your patch. Looking at the patch. Counting {{storagesSeen}} does work for your test case. But it is somewhat confusing, as the count is changing with interleaving reports. Suppose you have 3 storages (s1, s2, s3) and two block reports br1, br2 interleaving in the following way: || reoprtId-strorage || storagesSeen || | br1-s1 | 0 | | br1-s2 | 1 | | br2-s1 | 0 | | br2-s2 | 1 | | br1-s3 | 0 | The last line is confusing, because it should have been 2, but its is 0 since br2 overridden {{lastBlockReportId}} for s1 and s2 . This brought me to an idea. BR ids are monotonically increasing. What if in {{BlockManager.processReport()}} (before processing but under the lock) we check {{lastBlockReportId}} for all storages, and if we see one greater than {{context.getReportId()}} we through an {{IOExcpetion}} indicating that the next block report is in progress and we do not need to continue with this one. The exception is not expected to be passed back to the DataNode, as it has already timed out, but even if it gets passed, the DataNode will just send another block report. I think this could be a simple fix for this jira, and we can discuss other approaches to zombie storage detection in the next issue. Current approach seems to be error prone. One way is to go with the retry cache as [~jingzhao] suggested. Or there could be other ideas. > BlockReport retransmissions may lead to storages falsely being declared > zombie if storage report processing happens out of order > -------------------------------------------------------------------------------------------------------------------------------- > > Key: HDFS-10301 > URL: https://issues.apache.org/jira/browse/HDFS-10301 > Project: Hadoop HDFS > Issue Type: Bug > Components: namenode > Affects Versions: 2.6.1 > Reporter: Konstantin Shvachko > Assignee: Colin Patrick McCabe > Priority: Critical > Attachments: HDFS-10301.002.patch, HDFS-10301.003.patch, > HDFS-10301.01.patch, zombieStorageLogs.rtf > > > When NameNode is busy a DataNode can timeout sending a block report. Then it > sends the block report again. Then NameNode while process these two reports > at the same time can interleave processing storages from different reports. > This screws up the blockReportId field, which makes NameNode think that some > storages are zombie. Replicas from zombie storages are immediately removed, > causing missing blocks. -- This message was sent by Atlassian JIRA (v6.3.4#6332)