[
https://issues.apache.org/jira/browse/HDFS-3585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13405167#comment-13405167
]
Todd Lipcon commented on HDFS-3585:
-----------------------------------
If I follow correctly, you're saying that the BR contains the block with
GS=1002, but the NN has already seen the synchronization at GS=1003, so it
marks blk_1002 as corrupt.
Shoudln't this be OK? i.e the NN will then issue deletion of the replica with
GS=1002, the DN will ignore it because the GS doesn't match, and the corrupt
block entry will go away?
> Blocks are getting marked as corrupt when commitblocksyncronization(Since
> recovery called by another client) is success before BR send
> --------------------------------------------------------------------------------------------------------------------------------------
>
> Key: HDFS-3585
> URL: https://issues.apache.org/jira/browse/HDFS-3585
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: name-node
> Affects Versions: 2.0.1-alpha, 3.0.0
> Reporter: Brahma Reddy Battula
> Assignee: Todd Lipcon
>
> Scenario:
> ===========
> Writing files without close
> renaming file
> deleting files with four DN's and replication factor=3
--
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
