[
https://issues.apache.org/jira/browse/HADOOP-5134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12672760#action_12672760
]
dhruba borthakur commented on HADOOP-5134:
------------------------------------------
> But how about lease recovery when lease expires?
At this time, it should be safe to update the blocksMap. Since the file still
has a lease when the replicas are added to the blocksMap (via commitBlockSync),
the NN should not check/detect corrupt replicas.
HADOOP-5133 caused a problem because the client wrote more data to the block
after the first call to commitBlockSync(). However, when the NN triggers lease
recovery, the client cannot write any more data to the block. Thus, in this
case, it is safe for the NN to insert the replica in the blocksMap.
> FSNamesystem#commitBlockSynchronization adds under-construction block
> locations to blocksMap
> --------------------------------------------------------------------------------------------
>
> Key: HADOOP-5134
> URL: https://issues.apache.org/jira/browse/HADOOP-5134
> Project: Hadoop Core
> Issue Type: Bug
> Components: dfs
> Affects Versions: 0.18.2
> Reporter: Hairong Kuang
> Assignee: dhruba borthakur
> Priority: Blocker
> Fix For: 0.18.4
>
> Attachments: commitBlockSync.patch
>
>
> From my understanding of sync/append design, an under construction block
> should not have any block locations associated with it in the blocksMap. So
> an under construction block will not be managed by ReplicationMonitor.
> However, if there is an error in the write pipeline, a lease recovery will
> trigger a call, commitBlockSynchronization, to NN. This call will add the
> successfully-recovered datanodes to blocksMap. This seems to violate the
> design. It should update the targets of the last block at INode instead.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
