From owner-freebsd-current@FreeBSD.ORG  Thu Apr 21 21:18:28 2011
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: freebsd-current@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 07DDF1065670
	for <freebsd-current@freebsd.org>; Thu, 21 Apr 2011 21:18:28 +0000 (UTC)
	(envelope-from oberman@es.net)
Received: from mailgw.es.net (mail1.es.net [IPv6:2001:400:201:1::2])
	by mx1.freebsd.org (Postfix) with ESMTP id E74708FC16
	for <freebsd-current@freebsd.org>; Thu, 21 Apr 2011 21:18:27 +0000 (UTC)
Received: from ptavv.es.net (ptavv.es.net [IPv6:2001:400:910::29])
	by mailgw.es.net (8.14.3/8.14.3) with ESMTP id p3LLIQ78009147
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Thu, 21 Apr 2011 14:18:27 -0700
Received: from ptavv.es.net (localhost [127.0.0.1])
	by ptavv.es.net (Tachyon Server) with ESMTP id EAA151CC0F;
	Thu, 21 Apr 2011 14:18:25 -0700 (PDT)
To: Arnaud Lacombe <lacombar@gmail.com>
In-reply-to: Your message of "Thu, 21 Apr 2011 01:37:14 EDT."
	<BANLkTimCbWBs0_8oQh-_Qk-hxWxjnhXikw@mail.gmail.com> 
Date: Thu, 21 Apr 2011 14:18:25 -0700
From: "Kevin Oberman" <oberman@es.net>
Message-Id: <20110421211825.EAA151CC0F@ptavv.es.net>
Cc: Warren Block <wblock@wonkity.com>,
	FreeBSD-Current <freebsd-current@freebsd.org>,
	Benjamin Kaduk <kaduk@mit.edu>
Subject: Re: Switch from legacy ata(4) to CAM-based ATA 
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
	<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>, 
	<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Apr 2011 21:18:28 -0000

> Date: Thu, 21 Apr 2011 01:37:14 -0400
> From: Arnaud Lacombe <lacombar@gmail.com>
> Sender: owner-freebsd-current@freebsd.org
> 
> Hi,
> 
> On Wed, Apr 20, 2011 at 10:26 PM, Benjamin Kaduk <kaduk@mit.edu> wrote:
> > On Wed, 20 Apr 2011, Arnaud Lacombe wrote:
> >
> >> Hi,
> >>
> >> On Wed, Apr 20, 2011 at 9:17 PM, Warren Block <wblock@wonkity.com> wrote:
> >>>
> >>> On Wed, 20 Apr 2011, Arnaud Lacombe wrote:
> >>>
> >>>> On Wed, Apr 20, 2011 at 6:38 PM, Garrett Cooper <yanegomi@gmail.com>
> >>>> wrote:
> >>>>>
> >>>>> On Wed, Apr 20, 2011 at 3:35 PM, Doug Barton <dougb@freebsd.org> wrote:
> >>>>>
> >>>>> glabel create <label> /dev/<blah>
> >>>>
> >>>> Just tested that with a kernel from HEAD and a 8.x userland. This does
> >>>> not seem to survive a reboot.
> >>>
> >>> No, "create" makes a temporary label.  "label" writes a label to the last
> >>> block of the device.
> >>>
> >> ... which does not seem be doable when the fs is mounted:
> >>
> >> [in single-user, with only / mounted r/w and /dev]
> >> # geom label label root /dev/ad0s1a
> >> geom: Can't store metadata on /dev/ad0s1a: Operation not permitted.
> >
> > As an anti-foot-shooting measure, this is blocked unless the flag sysctl
> > kern.geom.debugflags |= 16 is set
> >
> unfortunately, that condition alone is not enough, the geom (not sure
> the term is correct) should also have a rank of 1, which is not the
> case on my [fairly standard ?] disk. Here is some more info from ddb:
> 
> db> show geom
> class: SWAP (0xc0875260)
> 
> class: DISK (0xc0853720)
>   geom: ad0 (0xc1d56900), rank=1
>     provider: ad0 (0xc1d56880), access=r1w1e3
>       consumer: 0xc20b9e40 (ad0), access=r1w1e3
>       consumer: 0xc20ba000 (ad0), access=r0w0e0
> 
> class: DEV (0xc0853600)
>   geom: ad0s1a (0xc1d56700), rank=4
>     consumer: 0xc20b9b00 (ad0s1a), access=r0w0e0
>   geom: ad0s1 (0xc1d56480), rank=3
>     consumer: 0xc20b9d80 (ad0s1), access=r0w0e0
>   geom: ad0 (0xc1d56780), rank=2
>     consumer: 0xc20ba000 (ad0), access=r0w0e0
> 
> class: LABEL (0xc0853ca0)
> 
> class: VFS (0xc0853c00)
>   geom: ffs.ad0s1a (0xc1d56c80), rank=4
>     consumer: 0xc20b9980 (ad0s1a), access=r1w1e1
> 
> class: PART (0xc0854520)
>   geom: ad0s1 (0xc1d56200), rank=3
>     provider: ad0s1a (0xc1d56100), access=r1w1e1
>       consumer: 0xc20b9980 (ad0s1a), access=r1w1e1
>       consumer: 0xc20b9b00 (ad0s1a), access=r0w0e0
>     consumer: 0xc20b9cc0 (ad0s1), access=r1w1e2
>   geom: ad0 (0xc1d56680), rank=2
>     provider: ad0s1 (0xc1d56580), access=r1w1e2
>       consumer: 0xc20b9cc0 (ad0s1), access=r1w1e2
>       consumer: 0xc20b9d80 (ad0s1), access=r0w0e0
>     consumer: 0xc20b9e40 (ad0), access=r1w1e3
> 
> So right now, I still have no transition mechanism from 8.x to 9.x,
> beside dropping in single user and edition /etc/fstab manually.
> 
> In the mean time, I'd assume that GEOM labels can be used in
> `vfs.root.mountfrom', am I right ?

Since the issue of labels and changes is under discussion, I have a pet
peeve that is in this area. 

For some reason that I can't fathom, the /dev/partition_format entries
that are created for /dev/ufs vanish when the device is mounted. Why?
This is not the case for ntfs, msdosfs, gpt, or any other. This
inconsistent behavior has resulted in lots of kludges in HAL and other
places and no one has ever given any good reason for it.

Worse, many operations on a UFS partition/file system cause a devd
create event even though there was no destroy event. I guess this is a
bug, though, so I can open a PR on it.
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman@es.net			Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751