[
https://issues.apache.org/jira/browse/HDFS-3107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13236075#comment-13236075
]
Tsz Wo (Nicholas), SZE commented on HDFS-3107:
----------------------------------------------
> ... The namenode RPC should have length as exactly a multiple of blocksize ...
Agree.
> Is this futureproof ? What happens where block storage becomes first class
> citizen ? Will we have an ability to create unowned block, and append it to
> an existing (truncated to block boundary) file ?
I think you mean separating namespace management and block management. The
beauty of truncate with concat is that it does not introduce new block level
operations so that there is no block management change (arguably, it makes
sense adding a new operation for copying an existing block to a new block so
that the copy can be done locally in datanodes but this not a big deal.) It
shouldn't cause any problem.
We don't need unowned block. The block should be owned by the user since the
data of the block is.
> 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
