svn commit: r220982 - in head: . sys/amd64/conf sys/arm/conf sys/conf sys/i386/conf sys/ia64/conf sys/mips/conf sys/mips/malta sys/pc98/conf sys/powerpc/conf sys/sparc64/conf sys/sun4v/conf

Alexander Motin mav at FreeBSD.org
Sun Apr 24 15:28:53 UTC 2011


Robert Watson wrote:
> I'm very pleased to see a continued movement towards the new ATA code;
> it offers clear benefits to all of our users, and is definitely
> something we want done for 9.0.
> 
> Could you say more about the migration strategy for users?  I recall
> that when you proposed throwing this switch, several strategies were
> discussed (likely in combination to handle both the immediate upgrade
> stumble issue and a longer-term migration):
> 
> (1) Teach new ata parts to replicate the old naming convention in 99.9% of
>     cases.  Or some suppport module that creates the required symlinks if
>     loaded (and we load it by default in 9.0, phasing it out later with
>     appropriate boot-time warnings for 6-12 months).  Obviously, this
> would be
>     best-effort, but if it takes us from a 40% upgrade failure to a 1%
> upgrade
>     failure, that's a big deal.
> 
> (2) Over time, provide a migration to fstab naming storage targets by
> volume
>     ID / name / serial number, rather than by hardware path.  A good
> long-term
>     strategy but one that requires changes to the installer, upgrade path,
>     etc.
> 
> (3) Teach freebsd-update/installer/etc to recognise *before* a new
> kernel is
>     installed whether the current configuration will require hand-holding.
> 
> (4) Thinking pretty hard about the roll-back path to avoid stumbles when
>     there's a problem following a kernel update.  In the past, linking
> kernel
>     feature updates to /etc or userspace updates has caused significant
> issues
>     for our users, who reasonably expect to follow our normal "install the
>     kernel, reboot, let it sit for a week" path.
> 
> What is your plan for implementing some combination of these (or did I
> miss the commits that brought them in already)?  In the past, we've seen
> upgrade path problems dislodge users, and since then, we've grown an
> increased assumption of ease-of-upgrade that can be managed
> automatically by tools like freebsd-update.  Breaking the automated
> upgrade (and roll-back) path would be extremely problematic.

I was hoping to not expand migration process onto another decade. Many
users already migrated to the new infrastructure on both STABLE and
CURRENT and AFAIK editing fstab was not a major problem for them. Since
the last big discussion of this question about year ago we got graid
implemented and some other things required to keep previous
functionality, that could hold users from migration. Making this commit
now I was prepared to spend few weeks on active bug fixing to minimize
number of further rollback cases. So at this moment device names change
is the last major problem I know. Yes, it was the same year ago, but
there was same discussion as the last week about using labels in fstab,
that equally ended with nothing. :(

What's about creating some kind of symlinks, it could be nice if it
worked, but I don't see the way to do it on disk(9) or GEOM layers
without breaking device's access counters and as result further random
problems.

Looking now on these "do or revert" demands to keep old device naming,
I'll try to make some hacks to CAM and ada(4) driver to mimic old "adX"
names. I see it in form of some loader tunable, disabled by default (as
it should be on newly installed systems), but that could be set prior to
upgrade if user doesn't want to bother with device names at that moment.
It should partially hide problem for some time.

Will such solution be acceptable?

-- 
Alexander Motin


More information about the svn-src-head mailing list