Date: Thu, 5 May 2011 17:23:39 +0400 From: Sergey Kandaurov <pluknet@gmail.com> To: Alexander Motin <mav@freebsd.org> Cc: FreeBSD-Current <freebsd-current@freebsd.org> Subject: Re: Switch from legacy ata(4) to CAM-based ATA Message-ID: <BANLkTinDLPybTLJ6z0Zdds9n_nQerJ8%2B1Q@mail.gmail.com> In-Reply-To: <4DAEAE1B.70207@FreeBSD.org> References: <4DAEAE1B.70207@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
2011/4/20 Alexander Motin <mav@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BANLkTinDLPybTLJ6z0Zdds9n_nQerJ8%2B1Q>