Switch from legacy ata(4) to CAM-based ATA

[Kevin Oberman]

> Date: Thu, 21 Apr 2011 01:37:14 -0400
> From: Arnaud Lacombe <lacombar at gmail.com>
> Sender: owner-freebsd-current at freebsd.org
> 
> Hi,
> 
> On Wed, Apr 20, 2011 at 10:26 PM, Benjamin Kaduk <kaduk at mit.edu> wrote:
> > On Wed, 20 Apr 2011, Arnaud Lacombe wrote:
> >
> >> Hi,
> >>
> >> On Wed, Apr 20, 2011 at 9:17 PM, Warren Block <wblock at wonkity.com> wrote:
> >>>
> >>> On Wed, 20 Apr 2011, Arnaud Lacombe wrote:
> >>>
> >>>> On Wed, Apr 20, 2011 at 6:38 PM, Garrett Cooper <yanegomi at gmail.com>
> >>>> wrote:
> >>>>>
> >>>>> On Wed, Apr 20, 2011 at 3:35 PM, Doug Barton <dougb at 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 at es.net			Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751