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

Surendra Singh Lilhore commented on HDFS-8946:
----------------------------------------------

*One suggestion :*

In this jira some logs are removed.
1.
{code}
if (requiredSize > remaining - scheduledSize) {
      logNodeIsNotChosen(storage, "the node does not have enough "
          + storage.getStorageType() + " space"
          + " (required=" + requiredSize
          + ", scheduled=" + scheduledSize
          + ", remaining=" + remaining + ")");
      return false;
    }
{code}

2. 
{code}
logNodeIsNotChosen(storage, "storage is read-only");
{code}

3.
{code}
logNodeIsNotChosen(storage, "storage has failed");
{code}

I think this is very important for debugging issue. From debug log we will get 
to know "why DN is not selected for block replication".

Can we add this back? At least first log should be there.

In HDFS-9023 some log improvement I want to do, when NN is not able to identify 
DN's for replication.


> Improve choosing datanode storage for block placement
> -----------------------------------------------------
>
>                 Key: HDFS-8946
>                 URL: https://issues.apache.org/jira/browse/HDFS-8946
>             Project: Hadoop HDFS
>          Issue Type: Improvement
>          Components: namenode
>            Reporter: Yi Liu
>            Assignee: Yi Liu
>             Fix For: 2.8.0
>
>         Attachments: HDFS-8946.001.patch, HDFS-8946.002.patch, 
> HDFS-8946.003.patch
>
>
> This JIRA is to:
> Improve chooseing datanode storage for block placement:
> In {{BlockPlacementPolicyDefault}} ({{chooseLocalStorage}}, 
> {{chooseRandom}}), we have following logic to choose datanode storage to 
> place block.
> For given storage type, we iterate storages of the datanode. But for 
> datanode, it only cares about the storage type. In the loop, we check 
> according to Storage type and return the first storage if the storages of the 
> type on the datanode fit in requirement. So we can remove the iteration of 
> storages, and just need to do once to find a good storage of given type, it's 
> efficient if the storages of the type on the datanode don't fit in 
> requirement since we don't need to loop all storages and do the same check.
> Besides, no need to shuffle the storages, since we only need to check 
> according to the storage type on the datanode once.
> This also improves the logic and make it more clear.
> {code}
>       if (excludedNodes.add(localMachine) // was not in the excluded list
>           && isGoodDatanode(localDatanode, maxNodesPerRack, false,
>               results, avoidStaleNodes)) {
>         for (Iterator<Map.Entry<StorageType, Integer>> iter = storageTypes
>             .entrySet().iterator(); iter.hasNext(); ) {
>           Map.Entry<StorageType, Integer> entry = iter.next();
>           for (DatanodeStorageInfo localStorage : DFSUtil.shuffle(
>               localDatanode.getStorageInfos())) {
>             StorageType type = entry.getKey();
>             if (addIfIsGoodTarget(localStorage, excludedNodes, blocksize,
>                 results, type) >= 0) {
>               int num = entry.getValue();
>               ...
> {code}
> (current logic above)



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

Reply via email to