[
https://issues.apache.org/jira/browse/HDFS-395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13087458#comment-13087458
]
Tsz Wo (Nicholas), SZE commented on HDFS-395:
---------------------------------------------
> > I think ReceivedDeletedBlockInfo is not needed. We may simply pass received
> > blocks and deleted blocks in separated arrays.
>
> I think this is a bad idea. The order of received and deleted is important. I
> would retain the existing code.
The order is important only if the same block is added or deleted multiple
times but the final result requires at most one add/delete operations. How
about we resolve the operations in the datanodes so that the namenode don't
have to add and delete the same block multiple times?
> DFS Scalability: Incremental block reports
> ------------------------------------------
>
> Key: HDFS-395
> URL: https://issues.apache.org/jira/browse/HDFS-395
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: data-node, name-node
> Reporter: dhruba borthakur
> Assignee: Tomasz Nykiel
> Attachments: blockReportPeriod.patch, explicitAcks.patch-3,
> explicitDeleteAcks.patch
>
>
> I have a cluster that has 1800 datanodes. Each datanode has around 50000
> blocks and sends a block report to the namenode once every hour. This means
> that the namenode processes a block report once every 2 seconds. Each block
> report contains all blocks that the datanode currently hosts. This makes the
> namenode compare a huge number of blocks that practically remains the same
> between two consecutive reports. This wastes CPU on the namenode.
> The problem becomes worse when the number of datanodes increases.
> One proposal is to make succeeding block reports (after a successful send of
> a full block report) be incremental. This will make the namenode process only
> those blocks that were added/deleted in the last period.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
