From owner-freebsd-current@FreeBSD.ORG Mon Apr 26 18:28:58 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 F1363106564A; Mon, 26 Apr 2010 18:28:58 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 8EBE78FC1B; Mon, 26 Apr 2010 18:28:58 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o3QIJavp060327; Mon, 26 Apr 2010 12:19:36 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 26 Apr 2010 12:19:46 -0600 (MDT) Message-Id: <20100426.121946.506212773266921087.imp@bsdimp.com> To: pjd@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <20100426181209.GB3012@garage.freebsd.pl> References: <4BD06BD9.6030401@FreeBSD.org> <20100426.103327.319083499807534535.imp@bsdimp.com> <20100426181209.GB3012@garage.freebsd.pl> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: mav@FreeBSD.org, freebsd-current@FreeBSD.org, 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: Mon, 26 Apr 2010 18:28:59 -0000 In message: <20100426181209.GB3012@garage.freebsd.pl> Pawel Jakub Dawidek writes: : On Mon, Apr 26, 2010 at 10:33:27AM -0600, M. Warner Losh wrote: : > I've read most of this thread. I think this is cool technology. : > However, before we move forward with this, we need to have a plan for : > the various issues that have come up. The plan needs to be specific, : > have owners for key items, warnings about ownerless == obsoleted, and : > target dates. : > : > I think this is one of the cases where we should record the plan of : > record on a wiki. It worked well for other times we've had big, : > disruptive changes. : > : > 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. : : This shouldn't be a bunch of GEOM classes. This should one class which : recognize multiple formats, just like the LABEL class. : I don't think it is feasible to reuse gmirror for that, it wasn't : designed in something like this in mind. OK. Maybe I got the consensus wrong... My key point is that we need a plan moving forward, we need to identify what's actively being worked on vs "somebody else[tm] should do tihs" and when it needs to be done "or else". : > (2) Send another big heads up strongly recommending people go to : > glabel based fstabs. Maybe the right option here is to provide a : > simple script walk people through the conversion. This will : > render the carnage of ad -> ada (or da) a mostly non-event, and : > also protect people from 'oops' of rebooting with that thumb drive : > in the system. : > (3) Create a wiki to record all the new geom classes needed. Find : > people to own each one, or note it is unowned, and support will be : > dropped if no owner can be found. : > (4) sysinstall should default to creating label systems, if it doesn't : > already. : > (5) Issues with glabel and ataraid(5) need an owner, and need to be : > resolved, since the device names here are likely to change. : : What are the issues? ataraid doesn't remove the underlying ad* devices, so glabel often picks those up instead of the ataraid device, and you only get 1 disk's worth of raid device... So no mirroring or only 1/2 a striped volume. Warner