hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Todd Lipcon (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-2865) Standby namenode gets a "cannot lock storage" exception during startup
Date Wed, 01 Feb 2012 01:56:57 GMT

    [ https://issues.apache.org/jira/browse/HDFS-2865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13197500#comment-13197500

Todd Lipcon commented on HDFS-2865:

If you have both NNs pointing to the same name dir, you will definitely have a problem. They
should not share a namedir, since they'll both try to acquire the lock. The fact that the
lock got deleted after the first failure is indeed a bug.
> 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


View raw message