hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Arpit Agarwal (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-11450) HDFS specific network topology classes with storage type info included
Date Tue, 28 Feb 2017 22:34:45 GMT

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

Arpit Agarwal commented on HDFS-11450:

Thanks for this improvement [~vagarychen]. The patch looks excellent! Comments are all nitpicks:
# DFSNetworkTopology#getInstance need not use {{ReflectionUtils.newInstance}}. It can call
{{new DFSNetworkTopology}}.
# DFSTopologyNodeImpl#childrenStorageInfo should be final.
# In DFSTopologyNodeImpl#remove, the comment {{// if the parent node has no children, remove
the parent node...}} probably belongs after the synchronized block.
# Coding convention. The NetworkTopology class doesn't follow it but we should in new classes.
## Spaces around operators {{n.setLevel(this.level+1)}} etc.
## Space after closing parenthesis in cast {{(DatanodeDescriptor)n}} etc.
# We avoid acronyms for variable names like {{DatanodeDescriptor dd}}. You could call it {{dnDescriptor}}

I am still reviewing the test case.

> HDFS specific network topology classes with storage type info included
> ----------------------------------------------------------------------
>                 Key: HDFS-11450
>                 URL: https://issues.apache.org/jira/browse/HDFS-11450
>             Project: Hadoop HDFS
>          Issue Type: Sub-task
>          Components: namenode
>            Reporter: Chen Liang
>            Assignee: Chen Liang
>         Attachments: HDFS-11450.001.patch, HDFS-11450.002.patch
> This JIRA adds storage type info into network topology.
> More specifically, this JIRA adds a storage type map by extending {{InnerNodeImpl}} to
describe the available storages under the current node's subtree. This map is updated when
a node is added/removed from the subtree.
> With this info, when choosing a random node with storage type requirement, the search
could then decide to/not to go deeper into a subtree by examining the available storage types
> One to-do item still, is that, we might still need to separately handle the cases where
a Datanodes restarts, or a disk is hot-swapped, will file another JIRA in that case.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail: hdfs-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-help@hadoop.apache.org

View raw message