[
https://issues.apache.org/jira/browse/HADOOP-5027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12664369#action_12664369
]
Konstantin Shvachko commented on HADOOP-5027:
---------------------------------------------
> nextGenerationStamp(Block) should not update the block information in the
> NameNode since the update may fail.
The update has already failed, that is why you do the recovery in the first
place, right? So NN already may have a wrong generation stamp. I still don't
understand why nextGenerationStamp(Block) cannot change Block's gen stamp.
Another thing if you change {{blockReport}} to understand generation stamps,
then the same should be done for {{blockReceived()}}.
I have always been under the impression that generation stamp plays role only
during lease recovery, and that blockReport and blockReceived distinguish
blocks by their {{id = <block#> + <genStamp>}}. I would rather keep it that
simple if possible.
> Block report processing should compare gneration stamp
> ------------------------------------------------------
>
> Key: HADOOP-5027
> URL: https://issues.apache.org/jira/browse/HADOOP-5027
> Project: Hadoop Core
> Issue Type: Bug
> Components: dfs
> Reporter: Tsz Wo (Nicholas), SZE
> Fix For: 0.19.1
>
> Attachments: 5027_20090114.patch
>
>
> If a reported block has a different generation stamp then the one stored in
> the NameNode, the reported block will be considered as invalid. This is
> incorrect since blocks with larger generation stamp are valid.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
