[
https://issues.apache.org/jira/browse/HDFS-9441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15024587#comment-15024587
]
Kihwal Lee commented on HDFS-9441:
----------------------------------
I understand the purpose and that it may minimize breakages in short term, but
it is a bit odd to make an argument so generic where interface or api is
defined. Why don't we add a new method that accepts BlockCollection instead of
String and call it wherever applicable? Sure, some custom implementations
might break, but that's one time cost for getting it right. This jira has been
a known issue for a long time and I believe its importance and impact warrant a
slight one-time pain. If we do this, we need to document that those who want
to utilize BC or path in their implementation should implement both versions.
> 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
(v6.3.4#6332)
