Switchover to CAM ATA?
rwatson at FreeBSD.org
Mon Apr 26 18:13:21 UTC 2010
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
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 :-).
> 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
> (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 :)
> freebsd-current at freebsd.org mailing list
> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"
More information about the freebsd-current