From owner-freebsd-geom@FreeBSD.ORG Thu Apr 22 16:06:01 2010 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 58AA51065675 for ; Thu, 22 Apr 2010 16:06:01 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2D7838FC14 for ; Thu, 22 Apr 2010 16:06:00 +0000 (UTC) Received: by pwi9 with SMTP id 9so6275703pwi.13 for ; Thu, 22 Apr 2010 09:06:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=H1cUsTdD4tdQtPOwlug7uKSOxpxh9An8SuSfnEeghFo=; b=C2dZLCzV5cdYP//XRGPDeY+l9WJGiderZbRa9k73B40XoZkj7XaAiGke1M4uKjS8Tb efptL+MrPUL9nb5Bg9s5FBNdBbfwkj+ONDTufJNZyDgGY2rF6uDiwOpK4YuvX2j7aWwh HWjtinu5XEX2hVrGYcPBQim7ALgpa847kgTf0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=PBmZHIFmHyodyN2irE1LfxAdYf7lFxEOVVpsWlJ6M0D295o7web0iBym7apqOCQc77 TrzRYw8fmV2Hhvf1NwowL8zAoPQ90ggpxX8DGyqVtpw2vXPZHyfBrx/t65ogwW3oRy06 75CzGknKuTqB5Ra4kS9vaQ6IUlMD+p7AqsmCI= MIME-Version: 1.0 Received: by 10.231.18.74 with HTTP; Thu, 22 Apr 2010 08:42:04 -0700 (PDT) In-Reply-To: <4BD06BD9.6030401@FreeBSD.org> References: <4BD06BD9.6030401@FreeBSD.org> Date: Thu, 22 Apr 2010 08:42:04 -0700 Received: by 10.141.214.6 with SMTP id r6mr114942rvq.138.1271950924623; Thu, 22 Apr 2010 08:42:04 -0700 (PDT) Message-ID: From: Freddie Cash To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-geom@freebsd.org Subject: Re: Switchover to CAM ATA? X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 16:06:01 -0000 2010/4/22 Alexander Motin > 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