[
https://issues.apache.org/jira/browse/HDFS-9079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zhe Zhang updated HDFS-9079:
----------------------------
Attachment: HDFS-9079.05.patch
Many thanks for Walter's review! Attaching new patch to address the comments.
# Reverted change to shouldStop(). I realized the coordinator doesn't need to
{{setExternalError}} at all. An external error is defined by the mismatch b/w
local and coordinator genStamps:
{code}
@Override
protected boolean processDatanodeOrExternalError() throws IOException {
if (coordinator.getProposedGenStamp() >
getLocatedBlock().getBlock().getGenerationStamp()) {
setExternalError();
}
return super.processDatanodeOrExternalError();
}
{code}
We can further eliminate the external error altogether. Can be a separate JIRA.
# bq. Thread coordinator leaks
Good point. Addressed
# bq. The 2 healthy check duplicates,
Good suggestion. It's not actually a duplicate health check. It's rather to
avoid sending a failure event if coordinator already knows about the failure. I
refactored the code.
# bq. You insert a empty closed streamer. Why not just use the new concept
StreamerStatus.NULL
I tried leaving the element in {{streamers}} as null instead of a closed
streamer. The issue is that many places assume the
{{DFSOutputStream#streamer}} is long running. We need to update everywhere
calling {{getStreamer()}} to make it work. So leaving that part as is.
# bq. we can use coordinator to postpone setExternalError() to address #1
See point #1 in my comment above. It's already postponed.
> 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}
> 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.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
