From owner-freebsd-geom@FreeBSD.ORG Sat May 29 01:30:43 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 1293C1065670 for ; Sat, 29 May 2010 01:30:43 +0000 (UTC) (envelope-from spawk@acm.poly.edu) Received: from acm.poly.edu (acm.poly.edu [128.238.9.200]) by mx1.freebsd.org (Postfix) with ESMTP id A3B328FC15 for ; Sat, 29 May 2010 01:30:41 +0000 (UTC) Received: (qmail 57999 invoked from network); 29 May 2010 01:30:40 -0000 Received: from unknown (HELO ?192.168.0.2?) (spawk@96.224.221.101) by acm.poly.edu with AES256-SHA encrypted SMTP; 29 May 2010 01:30:40 -0000 Message-ID: <4C006DE8.6040701@acm.poly.edu> Date: Fri, 28 May 2010 21:29:12 -0400 From: Boris Kochergin User-Agent: Thunderbird 2.0.0.24 (X11/20100330) MIME-Version: 1.0 To: Andriy Gapon 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> <4BF8192D.10809@icyb.net.ua> In-Reply-To: <4BF8192D.10809@icyb.net.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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, 29 May 2010 01:30:43 -0000 Andriy Gapon wrote: > 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. > Yeah, that might make life tricky. Alexander Motin told me off-list that he could make PCI information available to GEOM for me, and I cheerfully accepted. In the meantime, in my GEOM module's .init function, I am taking down the chip IDs of all PCI devices in the PCIC_STORAGE class and PCIS_STORAGE_RAID subclass, along with their children (disks), so that the .taste function has access to PCI information when tasting a disk. This may stink of layer pollution, but I am structuring my code in such a way that makes it easy to switch to getting PCI information from GEOM when the functionality becomes available. -Boris