[
https://issues.apache.org/jira/browse/HDFS-3107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14148393#comment-14148393
]
Plamen Jeliazkov commented on HDFS-3107:
----------------------------------------
Thanks for the points, [~jingzhao]!
# I had a lurking suspicion that something was wrong with my snapshot check.
Thanks for catching that.
# The BEING_TRUNCATED state is basically just an extension of UNDER_RECOVERY
state; there should not be an issue with block reports then; the main purpose
of BEING_TRUNCATED is to "force" the DataNode to truncate the block to the new
length rather than let the DataNodes attempt to negotiate the size of the block
(as they would in regular recovery).
# I am OK with adding configuration option if general opinion is that I should.
I take it I should throw OperationNotSupportedException in such case?
I will upload a new patch with those points addressed.
> 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.patch, HDFS-3107.patch, HDFS-3107.patch,
> HDFS-3107.patch, HDFS_truncate.pdf, 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 was sent by Atlassian JIRA
(v6.3.4#6332)
