[
https://issues.apache.org/jira/browse/HDFS-10301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15259284#comment-15259284
]
Konstantin Shvachko commented on HDFS-10301:
--------------------------------------------
May be we should go with a different approach for this problem.
- *The problem.* NameNode thinks that the reporting DN has the following set of
storages <s1, s2, s3>. But the DataNode reports <s1, s2, s4>, because one of
its drives was replaced, reformatted, or taken out of service. The NameNode
should update the list of storages to the ones reported by the DataNode,
potentially removing some of them.
- *Constraints.* Single block report can be split into multiple RPCs. Within
single block-report-RPC NameNode processes each storage under a lock, but then
releases and re-acquires the lock for the next storage, so that multiple RPC
reports can interleave due to multi-threading.
- *Approach.* DN should report full list of its storages in the first
block-report-RPC. The NameNode first cleans up unreported storages and replicas
belonging them, then start processing the rest of block reports as usually.
So DataNodes explicitly report storages that they have, which eliminates
NameNode guessing, which storage is the last in the block report RPC.
I did not look if any changes in the RPC message structure are needed, but it
think that all necessary fields should be already present.
> BlockReport retransmissions may lead to storages falsely being declared
> zombie if storage report processing happens out of order
> --------------------------------------------------------------------------------------------------------------------------------
>
> Key: HDFS-10301
> URL: https://issues.apache.org/jira/browse/HDFS-10301
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: namenode
> Affects Versions: 2.6.1
> Reporter: Konstantin Shvachko
> Assignee: Colin Patrick McCabe
> Priority: Critical
> Attachments: HDFS-10301.002.patch, HDFS-10301.003.patch,
> HDFS-10301.01.patch, zombieStorageLogs.rtf
>
>
> When NameNode is busy a DataNode can timeout sending a block report. Then it
> sends the block report again. Then NameNode while process these two reports
> at the same time can interleave processing storages from different reports.
> This screws up the blockReportId field, which makes NameNode think that some
> storages are zombie. Replicas from zombie storages are immediately removed,
> causing missing blocks.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
