Re: Switchover to CAM ATA?

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