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

Uma Maheswara Rao G commented on HDFS-140:
------------------------------------------

Hi Todd,

 Thanks a lot for taking a look!

I have verified this in trunk codebase. this issue has been addressed already.

{code}
 public void removeBlock(Block block) {
    block.setNumBytes(BlockCommand.NO_ACK);
    addToInvalidates(block);
    corruptReplicas.removeFromCorruptReplicasMap(block);
    blocksMap.removeBlock(block);
  }
{code}

FsNameSystem#removePathAndBlock will invoke this API. This is making sure that, 
block has been removed from blocksMap.
It looks to me that 0.21 onwards, this issue has been fixed. But i did not get 
exact JIRA specific to this problem.

But I am using 20.2 version. When i profiled, i found that blockMap elements 
are growing. Observation is that, after blockreports, that has been come down.

So,By looking at the code, current versions in 20X( *20.205,20.206* ) also has 
this problem.

Thanks
Uma


                
> When a file is deleted, its blocks remain in the blocksmap till the next 
> block report from Datanode
> ---------------------------------------------------------------------------------------------------
>
>                 Key: HDFS-140
>                 URL: https://issues.apache.org/jira/browse/HDFS-140
>             Project: Hadoop HDFS
>          Issue Type: Bug
>    Affects Versions: 0.20.1
>            Reporter: dhruba borthakur
>            Assignee: Uma Maheswara Rao G
>             Fix For: 0.20.205.0
>
>         Attachments: HDFS-140.20security205.patch
>
>
> When a file is deleted, the namenode sends out block deletions messages to 
> the appropriate datanodes. However, the namenode does not delete these blocks 
> from the blocksmap. Instead, the processing of the next block report from the 
> datanode causes these blocks to get removed from the blocksmap.
> If we desire to make block report processing less frequent, this issue needs 
> to be addressed. Also, this introduces indeterministic behaviout to a a few 
> unit tests. Another factor to consider is to ensure that duplicate block 
> detection is not compromised.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to