[
https://issues.apache.org/jira/browse/HDFS-9289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14969979#comment-14969979
]
Chang Li commented on HDFS-9289:
--------------------------------
Hi [~eclark], I think the case you gave is not the same and the corrupt block
doesn't seem to be caused by gen stamp reverse mismatch. So your initial
pipeline has node 33, 48, 38. Then after pipeline update it has node 33, 45,
29. Then node 38 is marked corrupt due to gen stamp mismatch, which is what it
should be. Then node 29(with correct gen stamp) were told to replicate to some
other node, and then client report block node 29 as corrupt. This case of
corruption doesn't seem like to be caused by gen stamp mismatch on namenode
side but a report from client ("because client machine reported it")
> check genStamp when complete file
> ---------------------------------
>
> Key: HDFS-9289
> URL: https://issues.apache.org/jira/browse/HDFS-9289
> Project: Hadoop HDFS
> Issue Type: Bug
> Reporter: Chang Li
> Assignee: Chang Li
> Priority: Critical
> Attachments: HDFS-9289.1.patch
>
>
> we have seen a case of corrupt block which is caused by file complete after a
> pipelineUpdate, but the file complete with the old block genStamp. This
> caused the replicas of two datanodes in updated pipeline to be viewed as
> corrupte. Propose to check genstamp when commit block
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
