hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Colin Patrick McCabe (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-3107) HDFS truncate
Date Tue, 04 Nov 2014 19:05:35 GMT

    [ 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

View raw message