hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "sam rash (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HDFS-1218) 20 append: Blocks recovered on startup should be treated with lower priority during block synchronization
Date Tue, 22 Jun 2010 01:37:56 GMT

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

sam rash commented on HDFS-1218:
--------------------------------

1. how can there be a pipeline recovery by a client when the client goes down?  in client-initiated
recovery, it sends in the list of nodes which excludes the node that went down.  Even if a
node goes down and comes back up, it won't participate in recovery.

The only case I can see that this can occur is if the client is not the one to initiate lease
recovery--ie hard or soft limits in the NN.

I only point this out because I wonder if this recovery code can be simplified.  We already
pass in a flag that is a surrogate for indicating NN initiated lease recovery (closeFile ==
true => NN).  

maybe not, but I wanted to throw it out there.

2. hmm, i think i see, it's sort of like using RBW and RWR as 1 and 0, and tacking to the
genstamp so that you take the highest appended genstamp and take the shortest length of those
as the length of the block.  in this way, you are auto-incrementing the genstamp in a way...

but I think there's still an edge case:  

  i. client node has network trouble (slow, falls off) and transfer to next DN in pipeline
from primary slowed/stops (going to timeout)
  ii. DN-1 writes after putting bytes into network buffer
  iii. bytes make it to first DN disk, but do not leave OS network stack
  iv. DN-1 comes up before NN starts hard expiry lease recovery
  v. we use the other DNs length which is shorter

or do I misunderstand?


> 20 append: Blocks recovered on startup should be treated with lower priority during block
synchronization
> ---------------------------------------------------------------------------------------------------------
>
>                 Key: HDFS-1218
>                 URL: https://issues.apache.org/jira/browse/HDFS-1218
>             Project: Hadoop HDFS
>          Issue Type: Bug
>          Components: data-node
>    Affects Versions: 0.20-append
>            Reporter: Todd Lipcon
>            Assignee: Todd Lipcon
>            Priority: Critical
>             Fix For: 0.20-append
>
>         Attachments: hdfs-1281.txt
>
>
> When a datanode experiences power loss, it can come back up with truncated replicas (due
to local FS journal replay). Those replicas should not be allowed to truncate the block during
block synchronization if there are other replicas from DNs that have _not_ restarted.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message