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

2011/4/20 Alexander Motin <mav_at_freebsd.org>:
> Hi.
>
> With 9.0 release approaching quickly, I believe it the best time now to
> manage migration from legacy ata(4) ATA to the new CAM-based one. New
> ATA code present in the tree for more then a year now, used by many
> people and proved it's superior functionality and reliability. The only
> major issue with it now is the migration process. Sooner or later we
> have to pass it, but due to major UI and API changes we can't do it
> after 9.0 release. So I propose to do it the next Sunday (April 24) to
> have as much time for troubleshooting as possible.
>
> I have prepared the following patch to do it:
> http://people.freebsd.org/~mav/ata_switch.patch
>
> I haven't added geom_raid to the kernel configurations because we have
> no other GEOM classes there. But tell me if you thing I should.
>
> If somebody has any problems with new ATA stack, please repeat your
> tests with latest HEAD code and contact me if problem is still there.
> Next three weeks before BSDCan I am going to dedicate to fixing possibly
> remaining issues.
>

XENHVM uses it's own naming scheme and can name disks as daN or adN,
depending on virtual block device id. atapci0/ata0/ata1 devices still present
there (such as in Bruce Cran's dmesg), but no any disks attached from it:
instead, all of them hung from device/vbd/N.
[In a non-XENHVM mode they are attached from ataN channels, as usual.]

/*
 * Translate Linux major/minor to an appropriate name and unit
 * number. For HVM guests, this allows us to use the same drive names
 * with blkfront as the emulated drives, easing transition slightly.
 */

xenbusb_front0: <Xen Frontend Devices> on xenstore0
xenbusb_back0: <Xen Backend Devices> on xenstore0
xctrl0: <Xen Control Device> on xenstore0
xbd0: 17000MB <Virtual Block Device> at device/vbd/768 on xenbusb_front0
xbd0: attaching as ad0
GEOM: ad0s1: geometry does not match label (16h,63s != 255h,63s).
xbd1: 3812MB <Virtual Block Device> at device/vbd/2048 on xenbusb_front0
xbd1: attaching as da0
xbd2: 114439MB <Virtual Block Device> at device/vbd/2064 on xenbusb_front0
xbd2: attaching as da1

Probably, /sys/dev/xen/blkfront/blkfront.c needs updating by s/"ad"/"ada"/g;
or such. I believe, xen generates sequential numbers starting from zero
(or rather such numbers that can be converted to sequential numbers),
similar to what ATA_CAM does.

-- 
wbr,
pluknet