From owner-freebsd-geom@FreeBSD.ORG Sat May 22 17:49:38 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 28325106564A for ; Sat, 22 May 2010 17:49:38 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 697268FC0A for ; Sat, 22 May 2010 17:49:37 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id UAA02372; Sat, 22 May 2010 20:49:34 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1OFspK-0004J7-1H; Sat, 22 May 2010 20:49:34 +0300 Message-ID: <4BF8192D.10809@icyb.net.ua> Date: Sat, 22 May 2010 20:49:33 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100321) MIME-Version: 1.0 To: Boris Kochergin References: <4BD06BD9.6030401@FreeBSD.org> <20100426.103327.319083499807534535.imp@bsdimp.com> <1272367989.97887.47.camel@buffy.york.ac.uk> <31A502A0-DB53-4677-BF92-6DD826ED449C@samsco.org> <4BF2AD97.4010100@acm.poly.edu> In-Reply-To: <4BF2AD97.4010100@acm.poly.edu> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: Sat, 22 May 2010 17:49:38 -0000 on 18/05/2010 18:09 Boris Kochergin said the following: > Scott Long wrote: >> On Apr 27, 2010, at 5:33 AM, Gavin Atkinson wrote: >> >> >>> On Mon, 2010-04-26 at 10:33 -0600, M. Warner Losh wrote: >>> >>>> My opinion for the path forward: >>>> (1) Send a big heads up about the future of ataraid(5). It will be >>>> shot in the head soon, to be replaced be a bunch of geom classes >>>> for each different container format. At least that seems to be >>>> the rough consensus I've seen so far. We need worker bees to do >>>> many of these classes, although much can be mined from the ataraid >>>> code today. >>>> >>> Losing ataraid would be bad. I suspect there are a lot of installs >>> using it - especially as there is no way to create any other mirror from >>> sysinstall. However, I'm not actually sure that the functionality it >>> provides is easy to push down into GEOM. >>> >>> ataraid depends on knowing a lot about the underlying hardware, in order >>> to know which format of metadata to use. i.e. it needs to know that the >>> disks are attached to (say) a Highpoint controller. >>> >> >> This is unfortunately true, especially on older controllers. I think >> that there >> are reasonable ways to address this though, by having CAM SIMs provide a >> bit more information in their PATH_INQ response. >> >> Scott >> > I am thinking about trying to reimplement some ataraid stuff using GEOM > as a summer programming exercise. Browsing the ataraid code, I notice > that it tends to check both the PCI ID of the controller a disk is > connected to, and a magic string identifying vendor-specific metadata > belonging to the vendor of the controller. This leads me to believe that > a lot of the pseudo-RAID formats can be used in GEOM without any > knowledge of the controller type. Just keep in mind the case when an HDD was used with a controller from one vendor and then moved to a different system with a different controller. So, pseudo-RAID label on disk may be different from actual pseudo-RAID hardware. -- Andriy Gapon