[ https://issues.apache.org/jira/browse/HDFS-3122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mit Desai resolved HDFS-3122. ----------------------------- Resolution: Not a Problem Target Version/s: 0.23.3, 0.24.0 (was: 0.24.0, 0.23.3) Haven't heard anything yet. Resolving this issue. Feel free to reopen if anyone thinks the other way. > Block recovery with closeFile flag true can race with blockReport. Due to > this blocks are getting marked as corrupt. > -------------------------------------------------------------------------------------------------------------------- > > Key: HDFS-3122 > URL: https://issues.apache.org/jira/browse/HDFS-3122 > Project: Hadoop HDFS > Issue Type: Bug > Components: datanode, namenode > Affects Versions: 0.23.0, 0.24.0 > Reporter: Uma Maheswara Rao G > Assignee: Uma Maheswara Rao G > Priority: Critical > Attachments: blockCorrupt.txt > > > *Block Report* can *race* with *Block Recovery* with closeFile flag true. > Block report generated just before block recovery at DN side and due to N/W > problems, block report got delayed to NN. > After this, recovery success and generation stamp modifies to new one. > And primary DN invokes the commitBlockSynchronization and block got updated > in NN side. Also block got marked as complete, since the closeFile flag was > true. Updated with new genstamp. > Now blockReport started processing at NN side. This particular block from RBW > (when it generated the BR at DN), and file was completed at NN side. > Finally block will be marked as corrupt because of genstamp mismatch. > {code} > case RWR: > if (!storedBlock.isComplete()) { > return null; // not corrupt > } else if (storedBlock.getGenerationStamp() != > iblk.getGenerationStamp()) { > return new BlockToMarkCorrupt(storedBlock, > "reported " + reportedState + " replica with genstamp " + > iblk.getGenerationStamp() + " does not match COMPLETE block's " + > "genstamp in block map " + storedBlock.getGenerationStamp()); > } else { // COMPLETE block, same genstamp > {code} -- This message was sent by Atlassian JIRA (v6.2#6252)