From owner-freebsd-current@FreeBSD.ORG Tue Apr 27 19:13:41 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D33031065674; Tue, 27 Apr 2010 19:13:41 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 752A88FC1B; Tue, 27 Apr 2010 19:13:41 +0000 (UTC) Received: from [127.0.0.1] (pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.14.3/8.14.3) with ESMTP id o3RJDb8h004747; Tue, 27 Apr 2010 13:13:37 -0600 (MDT) (envelope-from scottl@samsco.org) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Scott Long In-Reply-To: <1272367989.97887.47.camel@buffy.york.ac.uk> Date: Tue, 27 Apr 2010 13:13:37 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <31A502A0-DB53-4677-BF92-6DD826ED449C@samsco.org> References: <4BD06BD9.6030401@FreeBSD.org> <20100426.103327.319083499807534535.imp@bsdimp.com> <1272367989.97887.47.camel@buffy.york.ac.uk> To: Gavin Atkinson X-Mailer: Apple Mail (2.1078) X-Spam-Status: No, score=-1.0 required=3.8 tests=ALL_TRUSTED, T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on pooker.samsco.org Cc: mav@FreeBSD.org, freebsd-current@FreeBSD.org, "M. Warner Losh" , freebsd-geom@FreeBSD.org Subject: Re: Switchover to CAM ATA? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2010 19:13:41 -0000 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. >=20 > 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. >=20 > 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