From owner-freebsd-current@FreeBSD.ORG Mon Apr 26 18:13:20 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 F28CC1065675; Mon, 26 Apr 2010 18:13:20 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id AE87A8FC0A; Mon, 26 Apr 2010 18:13:20 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 443D346B35; Mon, 26 Apr 2010 14:13:20 -0400 (EDT) Date: Mon, 26 Apr 2010 19:13:20 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: "M. Warner Losh" In-Reply-To: <20100426.103327.319083499807534535.imp@bsdimp.com> Message-ID: References: <4BD06BD9.6030401@FreeBSD.org> <20100426.103327.319083499807534535.imp@bsdimp.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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:13:21 -0000 On Mon, 26 Apr 2010, 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. This is my reading too: this is a big deal change, it's excellent that it's happening, but if we want it to go well we need to do a bit of planning. In particular, if we want to maximize our effectiveness in convincing people to write replacements parts for ataraid, doing the heads up and schedule/warnings the right way will help a lot. While the schedule doesn't need to be as long as the mpsafe network stack/device drivers process, it worked well in practice and so I'd encourage something similar. More generally, and to raise a point not so much in your list: I wonder if global-based fstabs are the right way to go or not. If they are we need to push the migration heavily, and especially provide a pre-upgrade tool to help users get their fstab changes right (i.e., a script that takes your /etc/fstab and system configuration and tells you what to put in your new fstab). I still wonder if we should be trying a bit harder to provide compatibility with the old ata names -- our experience is that "flag day" upgrades cause a lot of user attrition on -current and in the releases, and it might be that making a few architectural sacrifices to ease the upgrade path is worth it. I for one don't want to be on the wrong end of all the users who install a new kernel and discover that /etc/fstab isn't forwards-compatible! All that said: this is really great work, and I'm sure I speak for many when I say thanks to Alexander for the hard work that has gone into this. A bit more perserverence and we'll be there :-). Robert > > 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. > (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. > (6) Someone needs to write-up a detailed description of how to do this > for UPDATING. Maybe we can reuse text from #2. > (7) We need a target time line for these things to happen. We can't > just break ataraid(5) by default with little or no warning. > Realistically, this will be for 9.0 and later systems, so we have > some time before the branch to give warning, as well as pull the > switch and have adequate testing time. > (8) Fill in all the parts that I've missed :) > > Comments? > > Warner > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >