Date: Thu, 22 Apr 2010 18:31:37 +0300 From: Alexander Motin <mav@FreeBSD.org> To: FreeBSD-Current <freebsd-current@freebsd.org> Cc: freebsd-geom@freebsd.org Subject: Switchover to CAM ATA? Message-ID: <4BD06BD9.6030401@FreeBSD.org>
next in thread | raw e-mail | index | archive | help
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? 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). -- Alexander Motin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4BD06BD9.6030401>