Date: Mon, 26 Apr 2010 19:13:20 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: "M. Warner Losh" <imp@bsdimp.com> Cc: mav@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-geom@FreeBSD.org Subject: Re: Switchover to CAM ATA? Message-ID: <alpine.BSF.2.00.1004261909220.241@fledge.watson.org> In-Reply-To: <20100426.103327.319083499807534535.imp@bsdimp.com> References: <4BD06BD9.6030401@FreeBSD.org> <20100426.103327.319083499807534535.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1004261909220.241>