[jira] [Commented] (HDFS-7980) Incremental BlockReport will dramatically slow down the startup of a namenode

[Yongjun Zhang (JIRA)]

    [ 
https://issues.apache.org/jira/browse/HDFS-7980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14482590#comment-14482590
 ] 

Yongjun Zhang commented on HDFS-7980:
-------------------------------------

Hi Guys,

Thanks for reporting and working on this jira. I have a question here.

Patch 001 does
{code}
  if (storageInfo.getBlockReportCount() == 0) {
        // The first block report can be processed a lot more efficiently than
        // ordinary block reports.  This shortens restart times.
        processFirstBlockReport(storageInfo, newReport);
      } else {
        invalidatedBlocks = processReport(storageInfo, newReport);
      }
      storageInfo.receivedBlockReport();
{code}

where  {{storageInfo.receivedBlockReport();}} increments the blockReportCount 
by 1, which means {{processFirstBlockReport(storageInfo, newReport);}} will be 
called only once (for the first block report, incremental or full).  

However, it's stated "We can still use processFirstBlockReport() even when 
storageInfo.numBlocks() > 0":
{quote}
How about the 001 patch? I think it works too. The first arrived incremental 
report only add a few block to NN. There is no need to calculate a toRemove 
list. We can still use processFirstBlockReport() even when 
storageInfo.numBlocks() > 0
{quote}

The question is, with patch 001, how can  {{processFirstBlockReport()}} be used 
even when storageInfo.numBlocks() > 0? I mean, after the first use of 
{{processFirstBlockReport()}}, blockReportCount is incremented by 1, thus 
preventing {{processFirstBlockReport()}} from being used again for later 
reports.

Thanks.




> Incremental BlockReport will dramatically slow down the startup of  a namenode
> ------------------------------------------------------------------------------
>
>                 Key: HDFS-7980
>                 URL: https://issues.apache.org/jira/browse/HDFS-7980
>             Project: Hadoop HDFS
>          Issue Type: Bug
>            Reporter: Hui Zheng
>            Assignee: Walter Su
>         Attachments: HDFS-7980.001.patch
>
>
> In the current implementation the datanode will call the 
> reportReceivedDeletedBlocks() method that is a IncrementalBlockReport before 
> calling the bpNamenode.blockReport() method. So in a large(several thousands 
> of datanodes) and busy cluster it will slow down(more than one hour) the 
> startup of namenode. 
> {code}
> List<DatanodeCommand> blockReport() throws IOException {
>     // send block report if timer has expired.
>     final long startTime = now();
>     if (startTime - lastBlockReport <= dnConf.blockReportInterval) {
>       return null;
>     }
>     final ArrayList<DatanodeCommand> cmds = new ArrayList<DatanodeCommand>();
>     // Flush any block information that precedes the block report. Otherwise
>     // we have a chance that we will miss the delHint information
>     // or we will report an RBW replica after the BlockReport already reports
>     // a FINALIZED one.
>     reportReceivedDeletedBlocks();
>     lastDeletedReport = startTime;
>     .........
>         // Send the reports to the NN.
>     int numReportsSent = 0;
>     int numRPCs = 0;
>     boolean success = false;
>     long brSendStartTime = now();
>     try {
>       if (totalBlockCount < dnConf.blockReportSplitThreshold) {
>         // Below split threshold, send all reports in a single message.
>         DatanodeCommand cmd = bpNamenode.blockReport(
>             bpRegistration, bpos.getBlockPoolId(), reports);
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)