hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Konstantin Shvachko (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-10301) BlockReport retransmissions may lead to storages falsely being declared zombie if storage report processing happens out of order
Date Sun, 07 Aug 2016 21:19:20 GMT

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

Konstantin Shvachko commented on HDFS-10301:

??the patch doesn't appear to close the race.??
It does. The problem is not that we release the lock, but that there is block-report-related
state in different places, particularly the BitSet in {{DatanodeDescriptor}}, see e.g. [this
under (1). The state can be reset by interleaving reports. So if we don't have the state there
is no race condition, because block reports are independent and can be processed in any order.
The path does just that it removes the block-report-tracking state. [See here|https://issues.apache.org/jira/browse/HDFS-10301?focusedCommentId=15259284&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15259284]
under Approach. In earlier version of the patch Vinitha introduced storage report as a separate
RPC, which was opposed by Colin. The latest patch incorporates the storage report with the
RPC for the last storage report. But the processing of all reports is still independent, therefore
releasing the lock is not a problem.
Just adding more details to Vinithas response.

??wouldn't something simple like this work???
I don't see how it will work. Not simple. The heartbeats can come at any time between reports
or between storages and update the reportId.

[~daryn], I think removing br-state substantially simplifies report processing and makes reports
independent (or idempotent), which is important by itself and solves the problem of interleaving
reports. The last patch solves the bug you reported (thanks) and provides a unit test for
it. As you see this jira was under development for quite a while. Would be good to commit
it soon. Do you still stand behind your veto given the latest patch?

> 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: Vinitha Reddy Gankidi
>            Priority: Critical
>             Fix For: 2.7.4
>         Attachments: HDFS-10301.002.patch, HDFS-10301.003.patch, HDFS-10301.004.patch,
HDFS-10301.005.patch, HDFS-10301.006.patch, HDFS-10301.007.patch, HDFS-10301.008.patch, HDFS-10301.009.patch,
HDFS-10301.01.patch, HDFS-10301.010.patch, HDFS-10301.011.patch, HDFS-10301.012.patch, HDFS-10301.013.patch,
HDFS-10301.branch-2.7.patch, HDFS-10301.branch-2.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

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

View raw message