[
https://issues.apache.org/jira/browse/HDFS-4420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Harsh J updated HDFS-4420:
--------------------------
Resolution: Duplicate
Target Version/s: (was: 2.0.3-alpha, 1.3.0)
Status: Resolved (was: Patch Available)
Although not implemented with the same idea, HDFS-6133 resolves this need via
DN block pinning. Reasoning versus using simple path to block lookup exclusion
is efficiency, as detailed further in Daryn's comments at
https://issues.apache.org/jira/browse/HDFS-6133?focusedCommentId=13980504&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13980504.
Resolving as Duplicate. Thanks for the patch effort regardless Max!
> Provide a way to exclude subtree from balancing process
> -------------------------------------------------------
>
> Key: HDFS-4420
> URL: https://issues.apache.org/jira/browse/HDFS-4420
> Project: Hadoop HDFS
> Issue Type: Improvement
> Components: balancer & mover
> Reporter: Max Lapan
> Priority: Minor
> Attachments: Balancer-exclude-subtree-0.90.2.patch,
> Balancer-exclude-trunk-v2.patch, Balancer-exclude-trunk-v3.patch,
> Balancer-exclude-trunk.patch, HDFS-4420-v4.patch
>
>
> During balancer operation, it balances all blocks, regardless of their
> filesystem hierarchy. Sometimes, it would be usefull to exclude some subtree
> from balancing process.
> For example, regionservers data locality is cruical for HBase performance.
> Region's data is tied to regionservers, which reside on specific machines in
> cluster. During operation, regionservers reads and writes region's data, and
> after some time, all this data are reside on local machine, so, all reads
> become local, which is great for performance. Balancer breaks this locality
> during opertation by moving blocks around.
> This patch adds [-exclude <path>] switch, and, if path is provided,
> balancer will not move blocks under this path during operation.
> Attached patch have tested for 0.90.2.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
