[
https://issues.apache.org/jira/browse/HDFS-3107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13237310#comment-13237310
]
Tsz Wo (Nicholas), SZE commented on HDFS-3107:
----------------------------------------------
> A problem of truncate is the "visibility". ...
@Zhanwei, The behavior of truncate should be similar to delete. For delete,
readers can continue reading the file after the file is deleted. The reader
will fail if it further talks to the Namenode. For truncate, it seems okay to
let the reader continue reading even beyond the truncated length and it will
fail when it talks to the Namenode. What do you think?
> One minor comment: please think about maintenance problems when you expose
> funky semantics ...
@M.C., I got your point. We probably should annotate the new API as unstable
or evolving in the first release.
> HDFS truncate
> -------------
>
> Key: HDFS-3107
> URL: https://issues.apache.org/jira/browse/HDFS-3107
> Project: Hadoop HDFS
> Issue Type: New Feature
> Components: data-node, name-node
> Reporter: Lei Chang
> Attachments: HDFS_truncate_semantics_Mar15.pdf,
> HDFS_truncate_semantics_Mar21.pdf
>
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
