[ 
https://issues.apache.org/jira/browse/HADOOP-1845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12525547
 ] 

Jim Kellerman commented on HADOOP-1845:
---------------------------------------

Until I saw the explanation above, it was disconcerting as it looked like there 
was something wrong with the DFS, especially since the log message is an ERROR. 
If it was an INFO, I would have assumed it was mostly harmless.

> Datanodes get error message "is valid, and cannot be written to" 
> -----------------------------------------------------------------
>
>                 Key: HADOOP-1845
>                 URL: https://issues.apache.org/jira/browse/HADOOP-1845
>             Project: Hadoop
>          Issue Type: Bug
>          Components: dfs
>    Affects Versions: 0.14.1
>            Reporter: Hairong Kuang
>             Fix For: 0.15.0
>
>
> >> Copy from dev list:
> Our cluster has 4 nodes and i set the mapred.subimt.replication parameter to 
> 2 on all nodes and the master. Everything has been restarted.
> Unfortuantely, we still have the same exception :
> 2007-09-05 17:01:59,623 ERROR org.apache.hadoop.dfs.DataNode:
> DataXceiver: java.io.IOException: Block blk_-5969983648201186681 is valid, 
> and cannot be written to.
>         at org.apache.hadoop.dfs.FSDataset.writeToBlock(FSDataset.java:515)
>         at
> org.apache.hadoop.dfs.DataNode$DataXceiver.writeBlock(DataNode.java:822)
>         at org.apache.hadoop.dfs.DataNode$DataXceiver.run(DataNode.java:727)
>         at java.lang.Thread.run(Thread.java:595)
> >> end of copy
> The message shows that the namenode schedules to replicate a block to a 
> datanode that already holds the block. The namenode block placement algorithm 
> makes sure that it does not schedule a block to a datanode that is confirmed 
> to hold a replica of the block. But it is not aware of any in-transit  block 
> placements (i.e. the scheduled but not confirmed block placements), so 
> occasionally we may still see "is valid, and cannot be written to" errors.
> A fix to the problem is to keep track of all in-transit block  placements, 
> and the block placement algorithm considers these  to-be-confirmed replicas 
> as well.

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

Reply via email to