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
Robert Watson
rwatson at FreeBSD.org
Sun Apr 24 10:48:21 UTC 2011
On Sun, 24 Apr 2011, Alexander Motin wrote:
> Author: mav
> Date: Sun Apr 24 08:58:58 2011
> New Revision: 220982
> URL: http://svn.freebsd.org/changeset/base/220982
>
> Log:
> Switch the GENERIC kernels for all architectures to the new CAM-based ATA
> stack. It means that all legacy ATA drivers are disabled and replaced by
> respective CAM drivers. If you are using ATA device names in /etc/fstab or
> other places, make sure to update them respectively (adX -> adaY,
> acdX -> cdY, afdX -> daY, astX -> saY, where 'Y's are the sequential
> numbers for each type in order of detection, unless configured otherwise
> with tunables, see cam(4)).
>
> ataraid(4) functionality is now supported by the RAID GEOM class.
> To use it you can load geom_raid kernel module and use graid(8) tool
> for management. Instead of /dev/arX device names, use /dev/raid/rX.
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.
Robert
More information about the svn-src-all
mailing list