From owner-svn-src-head@FreeBSD.ORG Sun Apr 24 10:48:20 2011 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E340A106564A; Sun, 24 Apr 2011 10:48:20 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id BC2808FC08; Sun, 24 Apr 2011 10:48:20 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 5E02846B49; Sun, 24 Apr 2011 06:48:20 -0400 (EDT) Date: Sun, 24 Apr 2011 11:48:20 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Alexander Motin In-Reply-To: <201104240858.p3O8wwqT024628@svn.freebsd.org> Message-ID: References: <201104240858.p3O8wwqT024628@svn.freebsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Apr 2011 10:48:21 -0000 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