Switchover to CAM ATA?

Freddie Cash fjwcash at gmail.com
Thu Apr 22 15:42:05 UTC 2010

2010/4/22 Alexander Motin <mav at freebsd.org>

> 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.

I haven't updated my 8-STABLE box in a couple of weeks.  Have the issues
with ATAPI DVD-burners been worked out, when using ATA_CAM?  Back in
Jan/Feb, thereabouts, I tested an ATA_CAM kernel and could not get a device
node of any kind to show up for the DVD burner (no acd0, no cd0, nothing in
dmesg).  A non-ATA_CAM kernel shows both acd0 and cd0.

Maybe I'll update my system this weekend and give ATA_CAM another test run.

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?
> If ataraid(4) should be reimplemented in GEOM, then how exactly? One
> more separate RAID infrastructure in GEOM (third?) looks excessive.
> Reuse gmirror, gstripe,... code would be nice, but will make them more
> complicated and could be not easy for RAID0+1 (due to common metadata)
> and RAID5 (due to lack of module in a base system).

If a lowly user's vote counts for anything, I'd vote for the complete
removal of ataraid support.  We have gstripe, gmirror, graid3, graid5, and
zfs (and gvinum for the masochistics).  :)  We don't need to support any of
the crappy pseudo-raid "hardware" out there.  ataraid(4) has served it's
purpose, tiding us over until GEOM RAID facilities were in place.  Now it's
time for it to be retired.

Freddie Cash
fjwcash at gmail.com

More information about the freebsd-current mailing list