Switchover to CAM ATA?

[Marius Strobl]

On Thu, Apr 22, 2010 at 06:31:37PM +0300, Alexander Motin wrote:
> Hi.
> 
> With time passed, CAM-based ATA infrastructure IMHO looks enough mature
> now to enable it in HEAD. Now we have two new stable drivers ahci(4) and
> siis(4), covering major part of modern SATA HBAs, `options ATA_CAM`
> wrapper for ata(4) to supports legacy hardware, and one more improved
> driver for Marvell HBAs (mvs) is now in development and soon will be
> present for testing. Together with many other people I have tested above
> at least on i386, amd64, arm and spart64 architectures.
> 
> This switchover would give us significant performance improvement on new
> hardware because of NCQ support in ahci/siis/mvs drivers; improved
> functionality, including SATA Port Multipliers support, better hot-plug
> support; and reduced code duplication between ata(4) and cam(4)
> subsystems and applications.
> 
> Two issues left at this moment are:
>  1) POLA breakage due to disk device being renamed from adX to adaY;
>  2) lack of araraid(4) alternative in new infrastructure. It should be
> reimplemented in GEOM in some way, but it still wasn't.
> 
> So what is the public opinion: Is the lack of ataraid(4) fatal or we can
> live without it?
> 
> Can we do switchover now, or some more reasons preventing this?
> 

As noted earlier, pc98 and sparc64 need ada(4)/CAM ATA to perform
geometry translation as done by ad_firmware_geom_adjust() for ad(4),
which the following patch hooks up to both:
http://people.freebsd.org/~marius/ata_disk_firmware_geom_adjust.diff
You preferred to implement such functionality via XPT_CALC_GEOMETRY
though (I'm still not convinced that it makes sense to put this
functionality into every ATA SIM the same way it is done for SCSI
rather than letting ada(4) handle it the same way for all SIMs
however). Have you looked into implementing XPT_CALC_GEOMETRY for
ATA CAM or is it okay to commit the above patch?

Marius