From owner-freebsd-stable@FreeBSD.ORG Sun Jul 4 15:37:09 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CAA26106566B for ; Sun, 4 Jul 2010 15:37:09 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 8B4058FC1F for ; Sun, 4 Jul 2010 15:37:09 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:7153:b6b4:eb9a:638a] (unknown [IPv6:2001:7b8:3a7:0:7153:b6b4:eb9a:638a]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id B742E5C43; Sun, 4 Jul 2010 17:37:08 +0200 (CEST) Message-ID: <4C30AAA8.7010206@andric.com> Date: Sun, 04 Jul 2010 17:37:12 +0200 From: Dimitry Andric User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.8pre) Gecko/20100703 Lanikai/3.1.1pre MIME-Version: 1.0 To: Daniel O'Connor References: <4C309359.8000502@andric.com> <791316F7-6E16-47D7-9B6C-2881FAAC78AA@gsoft.com.au> In-Reply-To: <791316F7-6E16-47D7-9B6C-2881FAAC78AA@gsoft.com.au> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Stable Subject: Re: GEOM/bsdlabel regression in 8.x? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jul 2010 15:37:09 -0000 On 2010-07-04 16:26, Daniel O'Connor wrote: >> First unmount /dev/md0s1a, or the device /dev/md0s1 will be in use, and >> opening it for read/write (as bsdlabel probably does) will fail. >> >> Alternatively, you can turn on the "footshooting" debug flag in geom: ... > It doesn't make a difference if you set that flag or not. > > (The fact you need to set debugflags to modify the MBR is a separate bug anyway IMO) On my 8-stable box, I have tried this sequence of commands: truncate -s 10m /tmp/test mdconfig -a -t vnode -f /tmp/test mdconfig -a -t vnode -f /tmp/test fdisk -BI /dev/md0 bsdlabel -w /dev/md0s1 bsdlabel -e /dev/md0s1 newfs /dev/md0s1a mkdir /mnt/test mount /dev/md0s1a /mnt/test bsdlabel -e /dev/md0s1 The last one indeed fails, because the device is in use. This is expected, but the error message is very misleading, and should be improved. The real 'bug' (although there will probably be loads of bikesheds about it) is probably that if you *do* unmount the filesystem, bsdlabel still fails: umount /mnt/test bsdlabel -e /dev/md0s1 [class not found yada yada] Apparently, unmounting does not properly 'release' whatever underlying geom device is preventing read/write access. However, if you then set the footshooting flag: sysctl -w kern.geom.debugflags=0x10 bsdlabel -e /dev/md0s1 bsdlabel can write without problems, at least on my box. Stranger even, if you subsequently turn off the footshooting flag, it *still* can write to the label. That is, unless you mount and unmount the filesystem, after which is again, sort of 'locked' against writing. All highly confusing. :)