[
https://issues.apache.org/jira/browse/HDFS-8697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14608885#comment-14608885
]
Zhe Zhang commented on HDFS-8697:
---------------------------------
Thanks Andrew for reviewing the patch!
bq. Explaining the expectations of decomming a DN with EC blocks somewhere
would be good too.
In the HDFS-7285 branch we do allow EC blocks to dip below full-strength
redundancy. We block decomm only if an EC block group is below minimum
redundancy (only {{dataBlockNum}} internal blocks left). We generalized
{{getExpectedReplicaNum}} and {{getMinStorageNum}} like below:
{code}
public short getExpectedReplicaNum(BlockCollection bc, BlockInfo block) {
if (block.isStriped()) {
return (short) (getStripedDataBlockNum(block) +
((BlockInfoStriped) block).getParityBlockNum());
} else {
return bc.getPreferredBlockReplication();
}
}
public short getMinStorageNum(BlockInfo block) {
if (block.isStriped()) {
return getStripedDataBlockNum(block);
} else {
return minReplication;
}
}
{code}
Good points about naming. We actually have HDFS-7955 (as a follow-on) to
systematically improve EC-replication related naming. Meanwhile the HDFS-7285
branch also includes some renaming. So how about we still leave class-level
renaming to HDFS-7955, and do method/variable renaming before merge? I can make
another pass of decomm manager to fix the _stored_ and log/comment naming.
> Refactor DecommissionManager: more generic method names and misc cleanup
> ------------------------------------------------------------------------
>
> Key: HDFS-8697
> URL: https://issues.apache.org/jira/browse/HDFS-8697
> Project: Hadoop HDFS
> Issue Type: New Feature
> Components: namenode
> Affects Versions: 2.7.0
> Reporter: Zhe Zhang
> Assignee: Zhe Zhang
> Attachments: HDFS-8697.00.patch
>
>
> This JIRA merges the changes in {{DecommissionManager}} from the HDFS-7285
> branch, including changing a few method names to be more generic
> ({{replicated}} -> {{stored}}), and some cleanups.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)