[
https://issues.apache.org/jira/browse/HDFS-5434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13848363#comment-13848363
]
Eric Sirianni commented on HDFS-5434:
-------------------------------------
bq. I sort of assumed when I read this JIRA that Eric was considering
situations where the admin "knows" that the storage is reliable despite having
only one replica.
Correct - thanks for jumping in.
bq. If the target storage is reliable then what do we gain by adding an extra
replica in the pipeline?
bq. Resiliency against transient network errors.
Yes, network errors, but also host failure. In the architecture we are
targeting, we use:
* RAID for resiliency to disk failure
* Shared storage for resiliency to host failure (this is enabled via an
{{FsDatasetSpi}} plugin that my team is developing)
These combine to make replicaCount=1 a viable alternative for some use cases.
However, the host failure resiliency via shared storage is only applicable once
the block is finalized after the initial write. Therefore, for a being-written
block, this architecture is still susceptible to data loss via host failure.
The solution proposed by this JIRA is to _temporarily_ use replicaCount=2
during the initial write pipeline (for host failure resiliency) and then drop
back to replicaCount=1 post-block-finalize (for storage efficiency).
The initial proposal was to control this in the NameNode by vending a pipeline
of length 2 even if the client requested replicaCount=1. In many ways, this is
a cleaner solution as it more directly models the desired architecture
(replicaCount is always 1, but pipeline length is forced to be > 1) . However,
Colin expressed some concerns about "overriding" the client's request at the
NameNode. We are considering at a client-side only approach as a fallback
alternative. Arpit - do you share Colin's concerns with the server-side
approach?
> 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.4#6159)
