[
https://issues.apache.org/jira/browse/HDFS-3702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13422372#comment-13422372
]
nkeywal commented on HDFS-3702:
-------------------------------
For a file open in writing, we will start with a call to ipc.Client to get the
last block length. The timeout in hdfs 1.0.3 is harcoded to 20s (fixed in
HADOOP-7397). Hence, anyway, HDFS-3704, but we can also hit HDFS-3701 at this
point, so it also a question of data loss. That's why we need to fix (HDFS-3701
and (HDFS-3702 or/and HDFS-3705 or/and HDFS-3703)).
For reducing the connect timeout, are you speaking about dfs.socket.timeout? Is
there a way to change it for connect timeout only?
> Add an option for NOT writing the blocks locally if there is a datanode on
> the same box as the client
> -----------------------------------------------------------------------------------------------------
>
> Key: HDFS-3702
> URL: https://issues.apache.org/jira/browse/HDFS-3702
> Project: Hadoop HDFS
> Issue Type: Improvement
> Components: hdfs client
> Affects Versions: 1.0.3, 2.0.0-alpha
> Reporter: nkeywal
> Priority: Minor
>
> This is useful for Write-Ahead-Logs: these files are writen for recovery
> only, and are not read when there are no failures.
> Taking HBase as an example, these files will be read only if the process that
> wrote them (the 'HBase regionserver') dies. This will likely come from a
> hardware failure, hence the corresponding datanode will be dead as well. So
> we're writing 3 replicas, but in reality only 2 of them are really useful.
--
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
