[ https://issues.apache.org/jira/browse/HDFS-9079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Zhe Zhang updated HDFS-9079: ---------------------------- Description: A non-striped DataStreamer goes through the following steps in error handling: {code} 1) Finds error => 2) Asks NN for new GS => 3) Gets new GS from NN => 4) Applies new GS to DN (createBlockOutputStream) => 5) Ack from DN => 6) Updates block on NN {code} With multiple streamer threads run in parallel, we need to correctly handle a large number of possible combinations of interleaved thread events. For example, {{streamer_B}} starts step 2 in between events {{streamer_A.2}} and {{streamer_A.3}}. HDFS-9040 moves steps 1, 2, 3, 6 from streamer to {{DFSStripedOutputStream}}. This JIRA proposes some further optimizations based on HDFS-9040: # We can preallocate GS when NN creates a new striped block group ({{FSN#createNewBlock}}). For each new striped block group we can reserve {{NUM_PARITY_BLOCKS}} GS's. If more than {{NUM_PARITY_BLOCKS}} errors have happened we shouldn't try to further recover anyway. # We can use a dedicated event processor to offload the error handling logic from {{DFSStripedOutputStream}}, which is not a long running daemon. # We can limit the lifespan of a streamer to be a single block. A streamer ends either after finishing the current block or when encountering a DN failure. With the proposed change, a {{StripedDataStreamer}}'s flow becomes: {code} 1) Finds DN error => 2) Notify coordinator (async, not waiting for response) => terminates 1) Finds external error => 2) Applies new GS to DN (createBlockOutputStream) => 3) Ack from DN => 4) Notify coordinator (async, not waiting for response) {code} was: A non-striped DataStreamer goes through the following steps in error handling: {code} 1) Finds error => 2) Asks NN for new GS => 3) Gets new GS from NN => 4) Applies new GS to DN (createBlockOutputStream) => 5) Ack from DN => 6) Updates block on NN {code} To simplify the above we can preallocate GS when NN creates a new striped block group ({{FSN#createNewBlock}}). For each new striped block group we can reserve {{NUM_PARITY_BLOCKS}} GS's. Then steps 1~3 in the above sequence can be saved. If more than {{NUM_PARITY_BLOCKS}} errors have happened we shouldn't try to further recover anyway. > Erasure coding: preallocate multiple generation stamps and serialize updates > from data streamers > ------------------------------------------------------------------------------------------------ > > Key: HDFS-9079 > URL: https://issues.apache.org/jira/browse/HDFS-9079 > Project: Hadoop HDFS > Issue Type: Sub-task > Components: erasure-coding > Affects Versions: HDFS-7285 > Reporter: Zhe Zhang > Assignee: Zhe Zhang > Attachments: HDFS-9079-HDFS-7285.00.patch, HDFS-9079.01.patch, > HDFS-9079.02.patch, HDFS-9079.03.patch, HDFS-9079.04.patch, HDFS-9079.05.patch > > > A non-striped DataStreamer goes through the following steps in error handling: > {code} > 1) Finds error => 2) Asks NN for new GS => 3) Gets new GS from NN => 4) > Applies new GS to DN (createBlockOutputStream) => 5) Ack from DN => 6) > Updates block on NN > {code} > With multiple streamer threads run in parallel, we need to correctly handle a > large number of possible combinations of interleaved thread events. For > example, {{streamer_B}} starts step 2 in between events {{streamer_A.2}} and > {{streamer_A.3}}. > HDFS-9040 moves steps 1, 2, 3, 6 from streamer to {{DFSStripedOutputStream}}. > This JIRA proposes some further optimizations based on HDFS-9040: > # We can preallocate GS when NN creates a new striped block group > ({{FSN#createNewBlock}}). For each new striped block group we can reserve > {{NUM_PARITY_BLOCKS}} GS's. If more than {{NUM_PARITY_BLOCKS}} errors have > happened we shouldn't try to further recover anyway. > # We can use a dedicated event processor to offload the error handling logic > from {{DFSStripedOutputStream}}, which is not a long running daemon. > # We can limit the lifespan of a streamer to be a single block. A streamer > ends either after finishing the current block or when encountering a DN > failure. > With the proposed change, a {{StripedDataStreamer}}'s flow becomes: > {code} > 1) Finds DN error => 2) Notify coordinator (async, not waiting for response) > => terminates > 1) Finds external error => 2) Applies new GS to DN (createBlockOutputStream) > => 3) Ack from DN => 4) Notify coordinator (async, not waiting for response) > {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)