hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tsz Wo Nicholas Sze (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-9441) Do not construct path string when choosing block placement targets
Date Wed, 02 Dec 2015 22:02:10 GMT

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

Tsz Wo Nicholas Sze commented on HDFS-9441:

In the past, the raid block placement policy by facebook used path to enforce storage scheme
(use raid or not).  I believe the parameter was added at that time.  After that no (known)
block placement policies use it for block placement.

> Do not construct path string when choosing block placement targets
> ------------------------------------------------------------------
>                 Key: HDFS-9441
>                 URL: https://issues.apache.org/jira/browse/HDFS-9441
>             Project: Hadoop HDFS
>          Issue Type: Improvement
>          Components: namenode
>            Reporter: Tsz Wo Nicholas Sze
>            Assignee: Tsz Wo Nicholas Sze
>            Priority: Minor
>         Attachments: h9441_20151118.patch, h9441_20151119.patch
> - INodeFile.getName() is expensive since it involves quite a few string operations. 
The method is called in both ReplicationWork and ErasureCodingWork but the default BlockPlacementPolicy
does not use the returned string.  We should simply pass BlockCollection to reduce unnecessary
computation when using the default BlockPlacementPolicy.
> - Another improvement: the return type of FSNamesystem.getBlockCollection should be changed
to INodeFile since it always returns an INodeFile object.

This message was sent by Atlassian JIRA

View raw message