Date: Sun, 24 Apr 2011 11:48:20 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Alexander Motin <mav@FreeBSD.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: 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 Message-ID: <alpine.BSF.2.00.1104241140070.36270@fledge.watson.org> In-Reply-To: <201104240858.p3O8wwqT024628@svn.freebsd.org> References: <201104240858.p3O8wwqT024628@svn.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1104241140070.36270>