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-unsubscr...@freebsd.org"
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
