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

On Apr 20, 2011, at 2:57 AM, Alexander Motin <mav_at_FreeBSD.org> wrote:

> 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

Although this may not be a list of fixable issues, here are some observations (in part with the new geom raid infrastructure):
1. Channels are no longer fixed of course because ata uses cam now, and I believe that device numbering is done based on probe ordering. This is fun to work with when dealing with appliances or configurations that require deterministic probe and mount, especially when drives fail, go missing, etc, but can be hacked around in device.hints. This is why it would be nice for geom labels to work in a sane manner.
2. When testing with USB thumb drives on 7.x with a custom kernel / sourcebase, it was enumerating the thumbdrive as da0, the first sata drive as ada1, etc. This may not be true for vanilla FreeBSD or later versions of FreeBSD.
3. Directly mappable analogs between atacontrol and camcontrol don't exist in areas; I'll come up with a laundry list for this because I said I would earlier via private email.
4. IIRC atacontrol and graid status reported different sets of raid volume states, depending on the underlying controller, in particular they changed the textual name for "healthy" from "optimal" to "ready" somewhere around the ICH7/8/9 era.
Thanks again for all your hard work!
-Garrett