Return-Path: Delivered-To: apmail-hadoop-hdfs-issues-archive@minotaur.apache.org Received: (qmail 79661 invoked from network); 17 Aug 2010 17:14:40 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 17 Aug 2010 17:14:40 -0000 Received: (qmail 62493 invoked by uid 500); 17 Aug 2010 17:14:40 -0000 Delivered-To: apmail-hadoop-hdfs-issues-archive@hadoop.apache.org Received: (qmail 62389 invoked by uid 500); 17 Aug 2010 17:14:39 -0000 Mailing-List: contact hdfs-issues-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: hdfs-issues@hadoop.apache.org Delivered-To: mailing list hdfs-issues@hadoop.apache.org Received: (qmail 62380 invoked by uid 99); 17 Aug 2010 17:14:39 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 17 Aug 2010 17:14:39 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.22] (HELO thor.apache.org) (140.211.11.22) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 17 Aug 2010 17:14:39 +0000 Received: from thor (localhost [127.0.0.1]) by thor.apache.org (8.13.8+Sun/8.13.8) with ESMTP id o7HHEIFl003968 for ; Tue, 17 Aug 2010 17:14:18 GMT Message-ID: <31118322.397791282065258246.JavaMail.jira@thor> Date: Tue, 17 Aug 2010 13:14:18 -0400 (EDT) From: "Todd Lipcon (JIRA)" 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 X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/HDFS-718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12899475#action_12899475 ] Todd Lipcon commented on HDFS-718: ---------------------------------- Woops, I forgot to watch this one and it just came back across my radar :) I don't see any harm in adding the config option suggested here - I was just wondering if there were another way of achieving the same goal without adding Even More Configs. So +0 from me. > 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-2.txt, 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.