[
https://issues.apache.org/jira/browse/HDFS-5478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13818644#comment-13818644
]
Vinay commented on HDFS-5478:
-----------------------------
bq. Duplicate of HDFS-4213. Only question is whether a normal hsync() or
hflush() should update this by default and without needing to cast-down, or
whether that is too expensive to happen by-default.
If we call update length by default, it will be expensive as every sync call
goes to namenode to update length which. So its better to keep it to user's
interest to update the length whenever required.
> File size reports as zero after writing and calling FSDataOutputStream#hsync()
> ------------------------------------------------------------------------------
>
> Key: HDFS-5478
> URL: https://issues.apache.org/jira/browse/HDFS-5478
> Project: Hadoop HDFS
> Issue Type: Bug
> Affects Versions: 2.0.0-alpha
> Environment: RHEL/OEL 6u3
> Reporter: Brett Randall
>
> Using a Java client to write to a FSDataOutputStream. After some data is
> written and hsync() is called, {{hdfs dfs -get /path/to/file}} gets a file
> containing the data written so-far, all good.
> {{hdfs dfs -ls /path/to/file}} however reports a zero-byte file, presumably
> until the stream is closed (it then shows the correct size). Hue File
> Browser (running CDH4) also shows zero bytes until the stream is closed.
> See also
> http://grokbase.com/t/hadoop/hdfs-user/113j63nrce/zero-file-size-after-hsync
> which discusses the same problem.
> After the buffer is flushed it would be good if the reported file size was
> updated.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
