[
https://issues.apache.org/jira/browse/HDFS-10206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15712724#comment-15712724
]
Nandakumar commented on HDFS-10206:
-----------------------------------
bq. nonDataNodeReader. However, it turns out NetworkTopology has several
existing references of "datanode". So It is good to have and up to you if you
want to fix it.
I thought nonDataNodeReader is explicit and easy to understand, and as you
mentioned there are several existing datanode reference in NetworkTopology.
bq. So 001.patch shouldn't has difference. Do you mind confirming?
Below is the micro-benchmark for SameNode and SameRack with the
[^HDFS-10206.002.patch]
|| Client on || Run 1 || Run 2 || Run 3 || Run 4 || Run 5 ||
| Same Node | 126994 | 95364 | 140242 | 119920 | 113167 |
| DataNode in same rack | 91442 | 124531 | 102606 | 104960 | 142946 |
bq. Can you confirm with 0002.patch the weights? It seems to return 0, 2, 4.
The old behavior is 0, 1, 2.
Yes, after the patch {{NetworkTopology.getWeight}} will return 0, 2, 4 ...
Below are few cases
*Same Node:*
/rack1/datanode1
/rack1/datanode1
Will return: 0
*Same Rack:*
/rack1/datanode1
/rack1/datanode2
Will return: 2
*Different Rack:*
/rack1/datanode1
/rack2/datanode3
Will return: 4
/dc1/rack1/datanode1
/default-rack/datanode4
Will return: 5
/dc1/rack1/datanode1
/dc2/rack5/datanode5
Will return: 6
> getBlockLocations might not sort datanodes properly by distance
> ---------------------------------------------------------------
>
> Key: HDFS-10206
> URL: https://issues.apache.org/jira/browse/HDFS-10206
> Project: Hadoop HDFS
> Issue Type: Improvement
> Reporter: Ming Ma
> Assignee: Nandakumar
> Attachments: HDFS-10206.000.patch, HDFS-10206.001.patch,
> HDFS-10206.002.patch
>
>
> If the DFSClient machine is not a datanode, but it shares its rack with some
> datanodes of the HDFS block requested, {{DatanodeManager#sortLocatedBlocks}}
> might not put the local-rack datanodes at the beginning of the sorted list.
> That is because the function didn't call {{networktopology.add(client);}} to
> properly set the node's parent node; something required by
> {{networktopology.sortByDistance}} to compute distance between two nodes in
> the same topology tree.
> Another issue with {{networktopology.sortByDistance}} is it only
> distinguishes local rack from remote rack, but it doesn't support general
> distance calculation to tell how remote the rack is.
> {noformat}
> NetworkTopology.java
> protected int getWeight(Node reader, Node node) {
> // 0 is local, 1 is same rack, 2 is off rack
> // Start off by initializing to off rack
> int weight = 2;
> if (reader != null) {
> if (reader.equals(node)) {
> weight = 0;
> } else if (isOnSameRack(reader, node)) {
> weight = 1;
> }
> }
> return weight;
> }
> {noformat}
> HDFS-10203 has suggested moving the sorting from namenode to DFSClient to
> address another issue. Regardless of where we do the sorting, we still need
> fix the issues outline here.
> Note that BlockPlacementPolicyDefault shares the same NetworkTopology object
> used by DatanodeManager and requires Nodes stored in the topology to be
> {{DatanodeDescriptor}} for block placement. So we need to make sure we don't
> pollute the NetworkTopology if we plan to fix it on the server side.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
