[
https://issues.apache.org/jira/browse/HDFS-9289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14979400#comment-14979400
]
Jing Zhao commented on HDFS-9289:
---------------------------------
bq. What if the updatePipeline RPC call has successfully finished NN side
changes but failed in sending response to client? Should we allow the client to
commit the block?
The RPC call will fail on the client side and the client will not use the old
GS to commit the block.
bq. How about we use this JIRA to commit the volatile change (which should fix
the reported issue) and dedicate a follow-on JIRA to the commitBlock GS
validation change?
I agree with this proposal. Let's only log a warning msg on the NN side but not
throw exception in this jira.
> 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, HDFS-9289.3.patch,
> HDFS-9289.4.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)
