Konstantin Shvachko commented on HDFS-10301:

??I don't think the lastBlockReportId code needs to all be gutted.??
{{lastBlockReportId}} was a part of the state introduced by HDFS-7960. It was 
removed for two reasons:
# It is not used anywhere after removing the state, so if we retain the field 
it causes a warning.
# The value of the field is non-deterministic and therefore not reliable.
   In case of competing reports with different IDs from the same DN there is no 
guarantee which value will be recorded in the field.

??the new location of {{curRpc + 1 == totalRpcs}} is arguably worse than the 
current location. I might be overlooking a detail??
The patch places the condition so that it is checked *_after_* all storage 
reports in the rpc are processed. That way the result (lease removal) does not 
depend on the order of processing storages within the block report processing 
queue. This is more important for single-RPC block reports, not so for 
per-storage-reports. It is intended to address [~arpitagarwal]'s concern.

??I've often stated how I intended/do-intend to make FBRs async.??
I don't think the patch prevents or makes it harder to implement async BRs. It 
removes dependency on the order of execution of reports by removing the 
BR-state. I think it benefits async BRs, because in current (sync case) the out 
of order reports is an abnormality, while in the async case it should be by 

[~daryn], you don't seem to object the latest patch. Please correct me if you 
do, and then indicate what you propose to move it forward.

> 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
>         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.014.patch, 
> HDFS-10301.015.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-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org

Reply via email to