From owner-freebsd-fs@FreeBSD.ORG Mon Apr 26 14:33:32 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1CBBD1065674; Mon, 26 Apr 2010 14:33:32 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id E28538FC14; Mon, 26 Apr 2010 14:33:31 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 95A5746B52; Mon, 26 Apr 2010 10:33:31 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id AF7438A021; Mon, 26 Apr 2010 10:33:27 -0400 (EDT) From: John Baldwin To: freebsd-fs@freebsd.org Date: Mon, 26 Apr 2010 09:59:00 -0400 User-Agent: KMail/1.12.1 (FreeBSD/7.3-CBSD-20100217; KDE/4.3.1; amd64; ; ) References: <201004230844.58047.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201004260959.00287.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Mon, 26 Apr 2010 10:33:27 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Ivan Voras Subject: Re: kern.geom.debugflags=16 does NOT allow me to write to device X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 14:33:32 -0000 On Friday 23 April 2010 11:18:58 am Ivan Voras wrote: > On 04/23/10 14:44, John Baldwin wrote: > > On Friday 23 April 2010 8:25:51 am Andriy Gapon wrote: > >> on 23/04/2010 13:34 Peter Schuller said the following: > >>>> It's easy. > >>> > >>> Thank you for posting the example. I never really understood that > >>> gpart was to be the generic tool; I thought it was gpt specific. > >>> Obviously I should have read up better. > >>> > >>> Is gpart to be considered "tested", "stable", "production quality" > >>> and/or "default" now then, or is it still cutting edge/experimental? > >> > >> Yes, it's "tested", "stable", "production quality" and/or "default". > >> All other tools are slowly rotting now, but can be fixed to correctly works via > >> GEOM interface the same way gpart does now. > >> E.g. see Andrey's work on sade(8). > > > > Actually, the other tools were already fixed to work properly with GEOM, but > > they used the older set of GEOM classes (GEOM_BSD, GEOM_MBR, etc.) instead > > of the GEOM_PART classes. > > It also depends on the meaning of "fixed" :) They mostly wrote to disk > drives directly from userland and relied on GEOM to pick up the changes > via the "spoil" mechanism - which is why they couldn't write to > partition tables if a file system on one of the partition was mounted, > etc., requiring hacks like kern.geom.debugflags=16 to drop the > permission (actually reference counting) checks. Not true. They sent verb actions to the modules to write updated sectors. Look at the write_disk() method in fdisk.c for example. It uses a verb for the GEOM_MBR class to update the MBR and only falls back to raw disk access if that fails. -- John Baldwin