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