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

Kihwal Lee commented on HDFS-5016:
----------------------------------

We need to guarantee that no unintended data modification occurs after block 
recoveries. If a writer could not be stopped right away, either 1) it has to 
stop writing when it unblocks, or 2) the block shouldn't be considered as 
recovered.

I think Suresh is saying 1) will happen and Nicholas is saying 2) will be 
safer. I agree with Suresh for this particular scenario, but am not 100% sure 
about all possible cases. E.g. if a writer is in the middle of slow disk write, 
it can continue to write. As a result, data on disk can get modified after 
successful recoverRbw(). I would prefer failing block recovery after timeout.


                
> Heartbeating thread blocks under some failure conditions leading to loss of 
> datanodes
> -------------------------------------------------------------------------------------
>
>                 Key: HDFS-5016
>                 URL: https://issues.apache.org/jira/browse/HDFS-5016
>             Project: Hadoop HDFS
>          Issue Type: Bug
>            Reporter: Devaraj Das
>            Assignee: Suresh Srinivas
>            Priority: Blocker
>             Fix For: 2.1.0-beta
>
>         Attachments: HDFS-5016.patch, jstack1.txt
>
>
> In the testing of some failure scenarios for HBase MTTR, we have been 
> simulating node failures via firewalling of nodes (where all communication 
> ports would be firewalled except ssh's port). We have noticed that when a 
> (data)node is firewalled, we lose certain other datanodes - those that were 
> involved in some communication with the firewalled node before the latter was 
> firewalled. Will attach jstack output from one of the lost datanodes. The 
> heartbeating thread seems to be locked up.
> This jira is to track a fix for the problem.

--
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

Reply via email to