[
https://issues.apache.org/jira/browse/HDFS-2034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John George updated HDFS-2034:
------------------------------
Attachment: HDFS-2034-2.patch
Good point about the "incomplete block being added to an offset larger than
file size". I completely agree with you that the function should ensure what it
sends back is what it was asked for. In that case, we should probably just
check for the requested offset. My concern with that specific assert is that,
with that assert, this function controls the behavior in cases where the user
requested for an offset > EOF, while the upper layer might specifically want a
different behavior (like sending back an EOF exception or just returning 0).
So, my take on this is that as long as the function behaves like it is asked
to, we should probably not assert.
Adding a new patch based on your suggestion about getFileLength().
Thanks again Daryn.
> length in getBlockRange becomes -ve when reading only from currently being
> written blk
> --------------------------------------------------------------------------------------
>
> Key: HDFS-2034
> URL: https://issues.apache.org/jira/browse/HDFS-2034
> Project: Hadoop HDFS
> Issue Type: Bug
> Reporter: John George
> Assignee: John George
> Priority: Minor
> Attachments: HDFS-2034-1.patch, HDFS-2034-1.patch, HDFS-2034-2.patch,
> HDFS-2034.patch
>
>
> This came up during HDFS-1907. Posting an example that Todd posted in
> HDFS-1907 that brought out this issue.
> {quote}
> Here's an example sequence to describe what I mean:
> 1. open file, write one and a half blocks
> 2. call hflush
> 3. another reader asks for the first byte of the second block
> {quote}
> In this case since offset is greater than the completed block length, the
> math in getBlockRange() of DFSInputStreamer.java will set "length" to
> negative.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
