Switchover to CAM ATA?

[Robert Watson]

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