[ 
https://issues.apache.org/jira/browse/HDFS-3107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14196619#comment-14196619
 ] 

Colin Patrick McCabe commented on HDFS-3107:
--------------------------------------------

bq. There is the option to treat the combined patch HDFS-3107-&-7056 as the 
first patch, which accounts for upgrade and rollback functionality as well as 
snapshot support, demonstrated in unit test.

That's fine with me.  It can go into trunk directly if it doesn't break 
rollback + snapshots.

bq. I am not objecting to do work on a branch but I am unsure it is necessary 
given the combined patch seems to meet the support requirements asked for this 
work.

I suggested a branch since I thought it would let us commit things quicker.  
But I don't think it's necessary if you can do things without breaking trunk.  
It is going to be no more than 3-4 patches anyway as I understand.  Whatever is 
easiest for you guys.

Just one request: Can you post the combined patch on a subtask rather than this 
JIRA?  I think having patches on this umbrella jira is very confusing.  If 
you're going to combine the patches, post the combined patch on either 
HDFS-7341 or HDFS-7056 please.  Thanks.

> HDFS truncate
> -------------
>
>                 Key: HDFS-3107
>                 URL: https://issues.apache.org/jira/browse/HDFS-3107
>             Project: Hadoop HDFS
>          Issue Type: New Feature
>          Components: datanode, namenode
>            Reporter: Lei Chang
>            Assignee: Plamen Jeliazkov
>         Attachments: HDFS-3107-HDFS-7056-combined.patch, HDFS-3107.008.patch, 
> HDFS-3107.patch, HDFS-3107.patch, HDFS-3107.patch, HDFS-3107.patch, 
> HDFS-3107.patch, HDFS-3107.patch, HDFS-3107.patch, HDFS-3107.patch, 
> HDFS_truncate.pdf, HDFS_truncate.pdf, HDFS_truncate.pdf, 
> HDFS_truncate_semantics_Mar15.pdf, HDFS_truncate_semantics_Mar21.pdf, 
> editsStored, editsStored.xml
>
>   Original Estimate: 1,344h
>  Remaining Estimate: 1,344h
>
> Systems with transaction support often need to undo changes made to the 
> underlying storage when a transaction is aborted. Currently HDFS does not 
> support truncate (a standard Posix operation) which is a reverse operation of 
> append, which makes upper layer applications use ugly workarounds (such as 
> keeping track of the discarded byte range per file in a separate metadata 
> store, and periodically running a vacuum process to rewrite compacted files) 
> to overcome this limitation of HDFS.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to