From owner-svn-src-all@FreeBSD.ORG Sun May 22 21:57:05 2011 Return-Path: Delivered-To: svn-src-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2101D10656D4; Sun, 22 May 2011 21:57:05 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id CF64C8FC12; Sun, 22 May 2011 21:57:04 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 618975DF8; Sun, 22 May 2011 21:57:03 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.4/8.14.4) with ESMTP id p4MLv2iW004780; Sun, 22 May 2011 21:57:02 GMT (envelope-from phk@critter.freebsd.dk) To: Marcel Moolenaar From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sun, 22 May 2011 13:28:35 MST." <6AE10D76-AC2F-4D7B-A985-EE072949ECC4@xcllnt.net> Content-Type: text/plain; charset=ISO-8859-1 Date: Sun, 22 May 2011 21:57:02 +0000 Message-ID: <4779.1306101422@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: Adrian Chadd , src-committers@FreeBSD.org, svn-src-all@FreeBSD.org, "Andrey V. Elsukov" , Stefan Farfeleder , svn-src-head@FreeBSD.org, Warner Losh Subject: Re: svn commit: r221972 - head/sys/geom/part X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2011 21:57:05 -0000 In message <6AE10D76-AC2F-4D7B-A985-EE072949ECC4@xcllnt.net>, Marcel Moolenaar writes: >Rather than just calling it a bad idea, why not come up with something >constructive? One thing I would like to point out, is that the potential for damage is very different in R/O and R/W mode. I think it would be prefectly justified to refuse a R/W open of a provider if there is credible reason to think that might ruin data. But I have a very hard time seeing the point in preventing a R/O open which would allow people to examine if there is an actual problem. At the most basic level, not creating the slices prevents people from even running "fsck_msdosfs -n /dev/da0s1" to get an idea if things are totally bonkers... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.