[
https://issues.apache.org/jira/browse/HDFS-5434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13811517#comment-13811517
]
Eric Sirianni commented on HDFS-5434:
-------------------------------------
We are proposing the default for {{dfs.namenode.minPipelineSize}} be 1 so
existing clients would be unaffected.
Yes, we've considered (and prototyped) the algorithm you suggested. However,
we are seeing environments where Hadoop Admins want to provide repcount=1 (with
resilient writes) transparently to Hadoop applications - in particular, those
for which it is not feasible to modify the file creation process (HBase, etc.).
Having a server-side configuration parameter seems like a cleaner way to
accomplish this. Server-side enforcement of pipeline size also seems somewhat
more complementary to where HDFS is headed with server-side tiered storage
policies (HDFS-4672).
Would you be more amenable to a patch that exposed the {{minPipelineSize}} as a
_client_ property ({{dfs.client.minPipelineSize}}) that implements the
algorithm you suggest above? This would give the us the end application
transparency we need, but still allow clients ultimate control of the pipeline
depth. This approach does have a few downsides compared to the server-side
approach:
* Does not allow the temporary replicas can be pruned incrementally as the file
is written (must wait until the file is closed)
* The replication remains at 2 if the client crashes before the file is closed
> 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)
