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

Raghu Angadi commented on HADOOP-1603:
--------------------------------------

Someone please double check what I have found till now. It looks like it exists 
in 13 also.

Before HADOOP-702, FSEditLog.adjustReplication() used to take conf as argument 
before. Not it just relies on min/max Replication  variables set in 
FSNamesystem object. But secondary name node uses a bare minimum which does 
have these variables set. So whenever Secondary namenode rolls the FSImage, it 
resets replication to 0 and when Namenode reads it in the next restart, it sets 
it to 1.

In my developement, for some reason many times Secondary Namenode never 
finishes creating new Image or it has some other exception.. never checked 
secondary namenode log till now. So this problem didn't always show up.


> Replication gets set to 1 sometimes when Namenode restarted.
> ------------------------------------------------------------
>
>                 Key: HADOOP-1603
>                 URL: https://issues.apache.org/jira/browse/HADOOP-1603
>             Project: Hadoop
>          Issue Type: Bug
>          Components: dfs
>    Affects Versions: 0.14.0
>            Reporter: Raghu Angadi
>            Assignee: Raghu Angadi
>            Priority: Blocker
>             Fix For: 0.14.0
>
>
> I have seen this with at least 3-4 weeks old trunk. It is not very 
> deterministic but when the cluster restarts all files get their replication 
> reset to 1. It is not deterministic but not very hard  to reproduce. I could 
> reproduce this on a small cluster. I will add more details. 

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