[
https://issues.apache.org/jira/browse/HDFS-9289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14976925#comment-14976925
]
Zhe Zhang commented on HDFS-9289:
---------------------------------
The fact that all 3 DNs have old GS doesn't mean the client also has an old GS.
Is the above log from the same cluster as previous [logs |
https://issues.apache.org/jira/browse/HDFS-9289?focusedCommentId=14972655&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14972655]?
In these cases, is there any replica with the correct (new) GS? If so it
doesn't look a bug. If all replicas of a block have old GS, then it's more
suspicious.
> 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, HDFS-9289.2.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)
