[
https://issues.apache.org/jira/browse/HDFS-4885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13783528#comment-13783528
]
Junping Du commented on HDFS-4885:
----------------------------------
Thanks Luke for review and great comments!
bq. I'd use something like hasMisplacement to check misplacement in fsck
instead of getMisReplicatedNum, as the latter might not be easy calculate for
certain BBPs. BlockPlacementStatus#getDescription is probably better than
either toString or getMisReplicatedString.
Sure. will update it.
bq. The advantage of this is that if we have (extended) attributes to implement
various placement grouping policies in the future, no API change is necessary.
Agree. Previous BlockPlacementConstraints is hard to extend to align with
different BPP, we should leave this flexibility to implementation of
verifyBlockPlacement() in different BPP but provide necessary info like
HdfsFileStatus.
bq. We should probably add a new API to calculate/reset the accumulative status
of a BBP instance, so a proper summary can be printed. This is also useful to
verify group (anti-)affinity, which cannot be determined on a block by block
basis.
That's a great idea. However, I guess it may be better to wait to implement
this until the BPP that based on (anti-) affinity group of blocks is ready,
then we can see how to extend BlockPlacementStatus (mostly seems to be merge
work) to status of a bunch of blocks. Thoughts?
Will address these comments soon.
> Update verifyBlockPlacement() API in BlockPlacementPolicy
> ---------------------------------------------------------
>
> Key: HDFS-4885
> URL: https://issues.apache.org/jira/browse/HDFS-4885
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Reporter: Junping Du
> Assignee: Junping Du
> Labels: BlockPlacementPolicy
> Attachments: HDFS-4885.patch, HDFS-4885-v2.patch
>
>
> verifyBlockPlacement() has unused parameter -srcPath as its responsibility
> just verify single block rather than files under a specific path. Also the
> return value (int) does not make sense as the violation of block placement
> has other case than number of racks, so boolean value should be better.
--
This message was sent by Atlassian JIRA
(v6.1#6144)