Mailing-List: contact hdfs-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Date: Thu, 2 Jun 2016 21:34:59 +0000 (UTC)
From: "Zhe Zhang (JIRA)" <jira@apache.org>
To: hdfs-issues@hadoop.apache.org
Message-ID: <JIRA.12959486.1460922644000.19824.1464903299567@Atlassian.JIRA>
In-Reply-To: <JIRA.12959486.1460922644000@Atlassian.JIRA>
References: <JIRA.12959486.1460922644000@Atlassian.JIRA> <JIRA.12959486.1460922644843@arcas>
Subject: [jira] [Commented] (HDFS-10301) BlockReport retransmissions may
 lead to storages falsely being declared zombie if storage report processing
 happens out of order
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Thu, 02 Jun 2016 21:35:06 -0000


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

Zhe Zhang commented on HDFS-10301:
----------------------------------

Thanks for the discussions [~cmccabe], [~shv],[~redvine]

I think the challenge here is that different deployments have different levels of 1) BR split; 2) BRs interleaving; 3) zombie storages. E.g. BR split might be completely turned off in configuration, and BR interleaving heavily depends on how busy the NN is.

*a)* Patch v5 (from Colin) works well when BRs rarely interleave. In the worst case, a zombie storage could remain on NN for several full-BR cycles.
*b)* Patch v4 (from Vinitha) works well when BRs are rarely split (or split into many RPCs). The worst case is where each BR is split into a small number of RPCs -- if each full BR is split into {{n}} RPCs, the relative overhead is 1 / n, in terms of # of RPCs.
*c)* As Colin suggested, we can also extend first / last RPC in a full BR with the list of storages. By doing that we are adding overhead to every BR RPC (it needs to mark whether it has the list). Theoretically, the worst-case-overhead is to add this to an empty BR.

So overall, I think c) is the best long term solution, because its worst case scenario is the least likely to happen, and the consequence is the most tolerable. It is more complex than b) though. Given the size of the v4 patch, are we OK to go with b) (v4 patch) first and do c) as a follow-on?

> 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.004.patch, HDFS-10301.005.patch, HDFS-10301.01.patch, HDFS-10301.sample.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)

---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-help@hadoop.apache.org