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

Suresh Srinivas commented on HDFS-7270:
---------------------------------------

[~daryn], let me understand the concerns. 

This feature has a configuration to turn it on or off. By default it is turned 
off.

There are two scenarios to consider:
# Rolling upgrades: Turning on this feature during rolling upgrades will result 
in some datanodes running old code and some running new. The incompatibility 
introduced in the feature will result in old clients not being able to talk to 
the upgraded node. However, the standard procedure for rolling upgrades is, not 
to turn on the new feature, while rolling upgrade is in progress. Hence the 
incompatibility should not affect rolling upgrades.
# Multi cluster environment running old and new releases: In this case, the 
feature should not be turned on. That is a simple choice for cluster admins.

[~wheat9], is there a way to support both old and new clients?

> Add congestion signaling capability to DataNode write protocol
> --------------------------------------------------------------
>
>                 Key: HDFS-7270
>                 URL: https://issues.apache.org/jira/browse/HDFS-7270
>             Project: Hadoop HDFS
>          Issue Type: Improvement
>          Components: datanode
>            Reporter: Haohui Mai
>            Assignee: Haohui Mai
>         Attachments: HDFS-7270.000.patch, HDFS-7270.001.patch, 
> HDFS-7270.002.patch, HDFS-7270.003.patch, HDFS-7270.004.patch
>
>
> When a client writes to HDFS faster than the disk bandwidth of the DNs, it  
> saturates the disk bandwidth and put the DNs unresponsive. The client only 
> backs off by aborting / recovering the pipeline, which leads to failed writes 
> and unnecessary pipeline recovery.
> This jira proposes to add explicit congestion control mechanisms in the 
> writing pipeline. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to