Skip site navigation (1)Skip section navigation (2)
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>