[ 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.