From owner-svn-src-all@FreeBSD.ORG Sun Apr 24 15:28:53 2011 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C5360106566C; Sun, 24 Apr 2011 15:28:53 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8EC4C8FC15; Sun, 24 Apr 2011 15:28:52 +0000 (UTC) Received: by bwz12 with SMTP id 12so1883540bwz.13 for ; Sun, 24 Apr 2011 08:28:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=3tfzIgQrd2esgkvDlGjboHE+sLMyHNXa+nYSEYccUhM=; b=aLGHIoBSpqes+fY71x31ruqw3QRMJ4/4fA2C+jKceoWw+OxgMvm3Dr6zVxvBbPCsJN LE7OkntXHVW6/LmiBD7pbejasZT79sHUKtQfIdNdBZx6E04Zhi+Fuc+YdxMbmYghc7o7 IbsFURF38iRVe6CqyWY42G7QXV3oWUE8MoSIE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=EUz1tyoyBPylsA+9z2xy3JCyLz5PmLikbdM1n8r2CR5GDSosU4OTUv+D6+iK0BgIAF Jtbg/k5H9VrOCpKIcx4MDvR9RKAraQIIuDBTA0TPqExI38GJti8fxaES4uTNrgn3iqYx X85OBx0soEaQU1nERiqUb39aIqEuT1zG3CFV4= Received: by 10.204.154.219 with SMTP id p27mr2639631bkw.110.1303658931183; Sun, 24 Apr 2011 08:28:51 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id w3sm2792693bkt.5.2011.04.24.08.28.49 (version=SSLv3 cipher=OTHER); Sun, 24 Apr 2011 08:28:50 -0700 (PDT) Sender: Alexander Motin Message-ID: <4DB441B0.8020906@FreeBSD.org> Date: Sun, 24 Apr 2011 18:28:48 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Robert Watson References: <201104240858.p3O8wwqT024628@svn.freebsd.org> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, "Bjoern A. Zeeb" 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-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Apr 2011 15:28:53 -0000 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