[
https://issues.apache.org/jira/browse/HDFS-3107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13237344#comment-13237344
]
M. C. Srivas commented on HDFS-3107:
------------------------------------
@Zhanwei and @TszWo: A comment on truncate & read interaction: The behavior
of the read() system call in Posix is to return fewer number of bytes than
asked for if EOF is encountered early. For example, if a file is of length 100
bytes, and a thread comes along and tries to read 200 bytes starting at offset
20, then read() should return 80. Subsequent calls to read() then return 0, to
indicate EOF. The same principle can be applied to a file that gets truncated
after it is opened for read ... treat it like a file that got shortened, ie, do
a short read the first time, and raise the EOF exception subsequently.
> 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
