[
https://issues.apache.org/jira/browse/HDFS-6830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15110039#comment-15110039
]
Vinayakumar B commented on HDFS-6830:
-------------------------------------
Hi [~xingfengshen],
According to case 2, block is not present in multiple storages, but its been
moved from one storage ( which NN thinks) to another storage ( which NN need to
know).
This Jira is about updating the NN's blocksmap with correct storage for the
block.
Datanode itself will not load duplicate replicas into replicas map. It will try
to resolve duplicates and retains the latest one during startup.
> BlockInfo.addStorage fails when DN changes the storage for a block replica
> --------------------------------------------------------------------------
>
> Key: HDFS-6830
> URL: https://issues.apache.org/jira/browse/HDFS-6830
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: namenode
> Affects Versions: 2.5.0
> Reporter: Arpit Agarwal
> Assignee: Arpit Agarwal
> Fix For: 2.6.0
>
> Attachments: HDFS-6830.01.patch, HDFS-6830.02.patch,
> HDFS-6830.03.patch, HDFS-6830.04.patch
>
>
> The call to {{removeStorageInfo}} is wrong because the block is still in the
> DatanodeStorage's list of blocks and the callee does not expect it to be.
> {code}
> } else {
> // The block is on the DN but belongs to a different storage.
> // Update our state.
> removeStorage(getStorageInfo(idx));
> added = false; // Just updating storage. Return false.
> }
> {code}
> It is a very unlikely code path to hit since storage updates usually occur
> via incremental block reports.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
