[
https://issues.apache.org/jira/browse/HDFS-2865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13197482#comment-13197482
]
Todd Lipcon commented on HDFS-2865:
-----------------------------------
Can you please include your configuration snippet for the various dirs?
The fact that it works on a second restart is probably in fact a bug - we used
to have some bug where, when the lock file prevented startup, we'd still
accidentally _remove_ the lock during a {{finally}} clause, which is clearly
incorrect. So after you've "successfully" started up, you may have two NNs
writing to the same dir and the world will explode.
> Standby namenode gets a "cannot lock storage" exception during startup
> ----------------------------------------------------------------------
>
> Key: HDFS-2865
> URL: https://issues.apache.org/jira/browse/HDFS-2865
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: ha, name-node
> Affects Versions: HA branch (HDFS-1623)
> Reporter: Hari Mankude
> Assignee: Hari Mankude
>
> Standby NN is restarted. This is a follow-on to hdfs-2863. In this setup,
> dfs.edits.dir is different from dfs.shared.edits.dir. During startup, standby
> NN fails to acquire lock on the dfs.edits.dir. If standby NN is restarted
> again, it seems to work fine.
--
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
