[
https://issues.apache.org/jira/browse/HADOOP-4663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12668203#action_12668203
]
dhruba borthakur commented on HADOOP-4663:
------------------------------------------
@Raghu: The hard-limit-lease-timeout is currently one hour. The NN will start
lease recovery after 1 hour. The lease recovery process locates the right
replicas (with the same size) bumps up the generation stamp on all these
datanode(s), and persists the new block id (that has the new generation stamp)
into the Inode. Since the inode map now has a new block id (because of the
change in gen stamp), all old replicas that have the old generation stamp do
not belong to any inode. If such a old block checks in with the NN via a block
report, it will get deleted. Does it sound right?
@Hairong: I get your proposal. I am starting to like it a lot!
>When a DataNode starts up, it reads blocks under tmp and put them to
>OngoingCreates data structure
Do we really need to do this? Even if we leave the blocks in the tmp directory,
it will be ok isn't it? A block report won't contain this block. But how does
it matter because the NN-blockreport-processing will always ignore the last
block of a file that is under construction. Now, when lease recovery occurs,
this block could move from the tmp directory to the real block directory.
> Datanode should delete files under tmp when upgraded from 0.17
> --------------------------------------------------------------
>
> Key: HADOOP-4663
> URL: https://issues.apache.org/jira/browse/HADOOP-4663
> Project: Hadoop Core
> Issue Type: Bug
> Components: dfs
> Affects Versions: 0.18.0
> Reporter: Raghu Angadi
> Assignee: dhruba borthakur
> Priority: Blocker
> Fix For: 0.19.1
>
> Attachments: deleteTmp.patch, deleteTmp2.patch, deleteTmp_0.18.patch,
> handleTmp1.patch
>
>
> Before 0.18, when Datanode restarts, it deletes files under data-dir/tmp
> directory since these files are not valid anymore. But in 0.18 it moves these
> files to normal directory incorrectly making them valid blocks. One of the
> following would work :
> - remove the tmp files during upgrade, or
> - if the files under /tmp are in pre-18 format (i.e. no generation), delete
> them.
> Currently effect of this bug is that, these files end up failing block
> verification and eventually get deleted. But cause incorrect over-replication
> at the namenode before that.
> Also it looks like our policy regd treating files under tmp needs to be
> defined better. Right now there are probably one or two more bugs with it.
> Dhruba, please file them if you rememeber.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
