hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "liaowenrui (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-3122) Block recovery with closeFile flag true can race with blockReport. Due to this blocks are getting marked as corrupt.
Date Thu, 22 Mar 2012 12:18:22 GMT

    [ https://issues.apache.org/jira/browse/HDFS-3122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13235530#comment-13235530

liaowenrui commented on HDFS-3122:

in this sence, delete data is very danger.it is very easy to loss data!

 solution that resolve this issue:

when namenode find replica with genstamp not match,the namenode require it's datanode re-report
block report´╝î
if it is still not match,the namenode mark it corrupt.

Are you right?
> 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: data-node, name-node
>    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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message