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

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

The append design explicitly states that the system should make every effort to 
persist data written to a file even is sync is not invoked. "sync" has some 
cost associated with it, and an application might not want to incur the cost at 
every write, but t would definitely like HDFS to make the best effort to 
persist that data it has written.

> it turned to be error-prone

The design is not error prone, it was the implementation that had some 
shortcomings. In particular, blocks that are part of replication requests 
should not have been promoted. This is fixed by this patch. If you are aware of 
other bugs in this area that can cause problems, it would be really nice if you 
can list it out or create a unit test to trigger that bug. I understand that 
the "append" protocol is complex, but when implemented correctly should be 
fool-proof.


>it adds performance overhead, when sync or append is not used.

are you concerned that renaming the block file from the blocksBeingWritten 
directory to the main block directory adds overhead to the write-pipeline? 

> 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