[
https://issues.apache.org/jira/browse/HADOOP-5015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12705205#action_12705205
]
Konstantin Shvachko commented on HADOOP-5015:
---------------------------------------------
This is a nice refactoring. A few comments:
# FSDirectory should have a method {{getBlockManager()}}. This will let you
avoid unnecessary transient methods in {{FSNamesystem}} that only exist to call
the respective {{BlockManager}} methods.
# {{BlocksWithLocations getBlocks()}} should remain in {{FSNamesystem}}. I
think {{BlockManager}} should not be exposed to external types like
{{BlocksWithLocations}}. Besides {{getBlocks()}} does not work with any
intrinsic fields of {{BlockManager}}.
# It seems to me that {{ReplicationTargetChooser replicator}} should be also
moved into {{BlockManager}}.
# I am not sure about the following fields, which may be related to block
management as well, but the patch left them inside {{FSNamesystem}}:
#- {{generationStamp}} seem to be related
#- {{blockInvalidateLimit}} looks like unrelated, we may later want to rename
it to {{datanodeInvalidateLimit}}.
#- {{ReplicationMonitor}} along with {{replicationRecheckInterval}} - probably
related.
> Seprate block/replica management code from FSNamesystem
> -------------------------------------------------------
>
> Key: HADOOP-5015
> URL: https://issues.apache.org/jira/browse/HADOOP-5015
> Project: Hadoop Core
> Issue Type: Improvement
> Components: dfs
> Reporter: Hairong Kuang
> Assignee: Suresh Srinivas
> Fix For: 0.21.0
>
> Attachments: blkmanager.patch
>
>
> Currently FSNamesystem contains a big amount of code that manages blocks and
> replicas. The code scatters in FSNamesystem and it is hard to read and
> maintain. It would be nice to move the code to a separate class called, for
> example, BlockManager.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.