Mailing-List: contact hdfs-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hdfs-issues@hadoop.apache.org
Message-ID: <2106503036.1257921915405.JavaMail.jira@brutus>
Date: Wed, 11 Nov 2009 06:45:15 +0000 (UTC)
From: "dhruba borthakur (JIRA)" <jira@apache.org>
To: hdfs-issues@hadoop.apache.org
Subject: [jira] Commented: (HDFS-718) configuration parameter to prevent
 accidental formatting of HDFS filesystem
In-Reply-To: <1834394332.1256078759417.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

dhruba borthakur commented on HDFS-718:
---------------------------------------

@Allen, thanks for your comments. Please let us know how you would like to change the "startup" message and why it helps accidental format's of the namenode. 

My thinking is that as far as "format" of HDFS is concerned, it is better to be safe than sorry. This patch leaves the default behaviour as it currently is; but is a boon for a paranoid administrator because he/she can rest assured that "bin/hadoop namenode -format" will not work against a NN that is configured with this option. Of course, there are plenty other ways to screw up the fsimage/edits files, but  if we can prevent some of the commonly-occuring scenarios, that will be helpful.

If the functionality of this patch already existed in HDFS, then my belief is that most  HDFS admins would probably already set this config parameter to prevent accidental formatting of namenode. 

> configuration parameter to prevent accidental formatting of HDFS filesystem
> ---------------------------------------------------------------------------
>
>                 Key: HDFS-718
>                 URL: https://issues.apache.org/jira/browse/HDFS-718
>             Project: Hadoop HDFS
>          Issue Type: Improvement
>          Components: name-node
>    Affects Versions: 0.22.0
>         Environment: Any
>            Reporter: Andrew Ryan
>            Assignee: Andrew Ryan
>            Priority: Minor
>         Attachments: HDFS-718.patch.txt
>
>
> Currently, any time the NameNode is not running, an HDFS filesystem will accept the 'format' command, and will duly format itself. There are those of us who have multi-PB HDFS filesystems who are really quite uncomfortable with this behavior. There is "Y/N" confirmation in the format command, but if the formatter genuinely believes themselves to be doing the right thing, the filesystem will be formatted.
> This patch adds a configuration parameter to the namenode, dfs.namenode.support.allowformat, which defaults to "true," the current behavior: always allow formatting if the NameNode is down or some other process is not holding the namenode lock. But if dfs.namenode.support.allowformat is set to "false," the NameNode will not allow itself to be formatted until this config parameter is changed to "true".
> The general idea is that for production HDFS filesystems, the user would format the HDFS once, then set dfs.namenode.support.allowformat to "false" for all time.
> The attached patch was generated against trunk and +1's on my test machine. We have a 0.20 version that we are using in our cluster as well.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.