hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kihwal Lee (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-3875) Issue handling checksum errors in write pipeline
Date Mon, 20 May 2013 17:59:18 GMT

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

Kihwal Lee commented on HDFS-3875:
----------------------------------

bq. Can you explain this sleep here a little further? The assumption is that the responder
will come back and interrupt the streamer? Why do we need to wait instead of just bailing
out immediately with the IOE? Will this cause a 3-second delay in re-establishing the pipeline
again?

This gives the responder time to send the checksum error back upstream, so that the upstream
node can blow up and exclude itself from the pipeline. This may not be always ideal since
there can be many different failure modes, but if anything needs to be eliminated without
knowing the cause, the source seems to be a better candidate than the sink who actually verifies
checksum.

Unless there is network issue in sending ACKs, responder will immediately terminate and interrupt
the main writer thread, so the thread won't stay up. Even if the thread stays up for some
reason, recoverRbw() during pipeline recovery will interrupt the thread, so there won't be
3 second delay.

If the last node in a pipeline has a faulty NIC, two upstream nodes will be eliminated (in
3 replica case) and after adding a new dn to the end of pipeline, the faulty node will be
removed. Issues on intermediate nodes will be handled in less number of iterations and the
worst case will be when data is corrupt in DFSOutputStream, which will be detected after hitting
the maximum number of retries. There will be no recovery in this case.
                
> Issue handling checksum errors in write pipeline
> ------------------------------------------------
>
>                 Key: HDFS-3875
>                 URL: https://issues.apache.org/jira/browse/HDFS-3875
>             Project: Hadoop HDFS
>          Issue Type: Bug
>          Components: datanode, hdfs-client
>    Affects Versions: 2.0.2-alpha
>            Reporter: Todd Lipcon
>            Assignee: Kihwal Lee
>            Priority: Critical
>         Attachments: hdfs-3875.branch-0.23.no.test.patch.txt, hdfs-3875.branch-0.23.patch.txt,
hdfs-3875.branch-0.23.patch.txt, hdfs-3875.branch-0.23.with.test.patch.txt, hdfs-3875.patch.txt,
hdfs-3875.patch.txt, hdfs-3875.trunk.no.test.patch.txt, hdfs-3875.trunk.no.test.patch.txt,
hdfs-3875.trunk.patch.txt, hdfs-3875.trunk.patch.txt, hdfs-3875.trunk.with.test.patch.txt,
hdfs-3875.trunk.with.test.patch.txt, hdfs-3875-wip.patch
>
>
> We saw this issue with one block in a large test cluster. The client is storing the data
with replication level 2, and we saw the following:
> - the second node in the pipeline detects a checksum error on the data it received from
the first node. We don't know if the client sent a bad checksum, or if it got corrupted between
node 1 and node 2 in the pipeline.
> - this caused the second node to get kicked out of the pipeline, since it threw an exception.
The pipeline started up again with only one replica (the first node in the pipeline)
> - this replica was later determined to be corrupt by the block scanner, and unrecoverable
since it is the only replica

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message