hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Colin Patrick McCabe (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-5434) Write resiliency for replica count 1
Date Mon, 28 Oct 2013 18:28:40 GMT

    [ https://issues.apache.org/jira/browse/HDFS-5434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13807064#comment-13807064
] 

Colin Patrick McCabe commented on HDFS-5434:
--------------------------------------------

Most users I am aware of who use replication factor 1 do it because they don't want the overhead
of a multi-datanode pipeline that writes to multiple datanodes.  If we give them such a pipeline
anyway, it's contrary to what replication factor 1 has always meant.

If your proposed solution works for you, there is a way to do it without modifying HDFS at
all.  Simply write with replication=2, and then call setReplication on the file after closing
it.

It seems like maybe your concern has more to do with how gracefully we handle pipeline failures
(currently, not very gracefully).  But that's a separate issue (see HDFS-4504 for details.)

> Write resiliency for replica count 1
> ------------------------------------
>
>                 Key: HDFS-5434
>                 URL: https://issues.apache.org/jira/browse/HDFS-5434
>             Project: Hadoop HDFS
>          Issue Type: Bug
>          Components: namenode
>    Affects Versions: 2.2.0
>            Reporter: Buddy
>            Priority: Minor
>
> If a file has a replica count of one, the HDFS client is exposed to write failures if
the data node fails during a write. With a pipeline of size of one, no recovery is possible
if the sole data node dies.
> A simple fix is to force a minimum pipeline size of 2, while leaving the replication
count as 1. The implementation for this is fairly non-invasive.
> Although the replica count is one, the block will be written to two data nodes instead
of one. If one of the data nodes fails during the write, normal pipeline recovery will ensure
that the write succeeds to the surviving data node.
> The existing code in the name node will prune the extra replica when it receives the
block received reports for the finalized block from both data nodes. This results in the intended
replica count of one for the block.
> This behavior should be controlled by a configuration option such as {{dfs.namenode.minPipelineSize}}.
> This behavior can be implemented in {{FSNameSystem.getAdditionalBlock()}} by ensuring
that the pipeline size passed to {{BlockPlacementPolicy.chooseTarget()}} in the replication
parameter is:
> {code}
> max(replication, ${dfs.namenode.minPipelineSize})
> {code}



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Mime
View raw message