Date: Thu, 22 Apr 2010 08:42:04 -0700 From: Freddie Cash <fjwcash@gmail.com> To: freebsd-current@freebsd.org Cc: freebsd-geom@freebsd.org Subject: Re: Switchover to CAM ATA? Message-ID: <n2ob269bc571004220842q57913d19kfe4196bc92581c4e@mail.gmail.com> In-Reply-To: <4BD06BD9.6030401@FreeBSD.org> References: <4BD06BD9.6030401@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
2010/4/22 Alexander Motin <mav@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@gmail.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?n2ob269bc571004220842q57913d19kfe4196bc92581c4e>