[
https://issues.apache.org/jira/browse/HDFS-1975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13158067#comment-13158067
]
Todd Lipcon commented on HDFS-1975:
-----------------------------------
bq. How about update the generation stamp after logging the new block
The issue is that we need the new block to have the new genstamp, so we have to
call {{nextGenerationStamp}} before we create the new block. Alternatively, we
could split up {{nextGenerationStamp}} into two parts -- one which increments,
and another which logs. But then we may have an issue if there is a crash so
the edit log includes the block allocation but not the SET_GENERATION_STAMP.
I've temporarily worked around this by changing the FSEditLogLoader code to
only call {{notifyGenStampUpdate}} in {{OP_ADD}}, not in {{OP_SET_GENSTAMP}}.
So, the new block is added to the block manager before it's notified as OK to
handle the DN messages.
*BUT* -- there's another issue with using genstamps as our "gating" mechanism
for the DN messages - comment to follow.
> HA: Support for sharing the namenode state from active to standby.
> ------------------------------------------------------------------
>
> Key: HDFS-1975
> URL: https://issues.apache.org/jira/browse/HDFS-1975
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: name-node
> Reporter: Suresh Srinivas
> Assignee: Jitendra Nath Pandey
> Attachments: HDFS-1975-HA.2.patch, HDFS-1975-HA.patch,
> HDFS-1975-HDFS-1623.patch, HDFS-1975-HDFS-1623.patch, hdfs-1975.txt,
> hdfs-1975.txt
>
>
> To enable hot standby namenode, the standby node must have current
> information for - namenode state (image + edits) and block location
> information. This jira addresses keeping the namenode state current in the
> standby node. To do this, the proposed solution in this jira is to use a
> shared storage to store the namenode state.
> Note one could also build an alternative solution by augmenting the backup
> node. A seperate jira could explore this.
--
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
