[
https://issues.apache.org/jira/browse/HDFS-2603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Todd Lipcon resolved HDFS-2603.
-------------------------------
Resolution: Duplicate
This work got incorporated into HDFS-1972
> HA: don't initialize replication queues until entering Active mode
> ------------------------------------------------------------------
>
> Key: HDFS-2603
> URL: https://issues.apache.org/jira/browse/HDFS-2603
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: ha
> Affects Versions: HA branch (HDFS-1623)
> Reporter: Todd Lipcon
> Assignee: Todd Lipcon
> Priority: Critical
>
> As described in the comments of HDFS-1975:
> 1) Active NN receives setReplication to drop some file's replication from 3
> to 1
> 2) It writes OP_SET_REPLICATION to its log, invalidates two replicas, and
> returns
> 3) The DNs report BLOCK_INVALIDATED back to both the ActiveNN and SBNN.
> 4) The SBNN hasn't received the OP_SET_REPLICATION yet, so it marks the block
> as under-replicated.
> In the case of raising replication (eg from 1 to 3) we get the opposite
> problem: the SBNN marks the block as over-replicated and adds two of the
> replicas to its invalidation list.
> Generation stamps don't help here, because changing replication level of a
> block doesn't change its gen-stamp (and it shouldn't). One possible answer is
> that we need to modify FSNamesystem.isPopulatingReplQueues to return false on
> the standby, and then when it switches from standby to active, initialize the
> replication queues only after reading the latest edits... I think that will
> solve the SET_REPLICATION issue, but not certain if it will solve all the
> issues in this general class.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
