[ 
https://issues.apache.org/jira/browse/HADOOP-4663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12669101#action_12669101
 ] 

dhruba borthakur commented on HADOOP-4663:
------------------------------------------

I have been thinking of Hairong's suggestion as well. I agree that it makes 
sense for the blocks inside "blocksBeingWritten" directory to not be 
auto-promoted, but instead make lease recovery promote them on demand. The only 
problem I had with this approach is that a "special" block report is needed. 

What if we have a block report always have two counters up front? the first 
counter will list the number of normal blocks in the block report. the second 
counter will have the number of blocks in the block report that are being 
picked up from the "blocksBeingWritten" directory? The NN, while processing a 
block report, will first look at the first counter and process those many 
blocks from the block report as usual. Then it will look at the second counter 
and will special-process those many blocks from the block report. 

> 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.

Reply via email to