From owner-svn-src-head@FreeBSD.ORG Sun Apr 24 18:59:45 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 6956E106564A; Sun, 24 Apr 2011 18:59:45 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id E1F638FC14; Sun, 24 Apr 2011 18:59:44 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id A1B4825D3857; Sun, 24 Apr 2011 18:59:43 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 04772159DB43; Sun, 24 Apr 2011 18:59:43 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id joRQkvUrB5sn; Sun, 24 Apr 2011 18:59:41 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 4ACA0159DB42; Sun, 24 Apr 2011 18:59:41 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: <4DB441B0.8020906@FreeBSD.org> Date: Sun, 24 Apr 2011 18:59:40 +0000 Content-Transfer-Encoding: 7bit Message-Id: References: <201104240858.p3O8wwqT024628@svn.freebsd.org> <4DB441B0.8020906@FreeBSD.org> To: Alexander Motin X-Mailer: Apple Mail (2.1084) Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Robert Watson 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 18:59:45 -0000 On Apr 24, 2011, at 3:28 PM, Alexander Motin wrote: > 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. Do not think that based on the hundred replies on the lists in two years, that any of the hundreds of thousands of machines you haven't heard of were migrated. A LOT of people simply run on defaults we provide. > ... 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. :( I am sorry if I was too direct with the "fix it the next weeks or backout" earlier today. As I had said on current@ I have migrated machines myself and am testing things where possible and it's a good thing to move to. As I had also said on current@ "we must not screw our users and need transition magic". I think a couple of others just didn't repeat what was said months ago. > 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. I had been pondering devfs "link"s myself, the problem is that from the rc framework they come too late. If you can add a simple .ko that does it programmatically on 9 that would be great. The problem is that after booting the new kernel you don't know whether people had ATA_STATIC on or not, so we'd have to go with the defaults, that were in 8.x (and an extra tunable to flip the logic maybe)? > 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. It would need to be in and on by default for the lifetime of 9 as it's not in the last 8.x release (which would need it the other way round anyway. MIght it be a good idea to do that as well afterwards providing ada links on the next 8.x release?). The user could disable it after the conversion happened though with a tunable to get rid of the extra /dev/* noise. We could even check for it being on and check fstab and warn/pester the user then that he'll need to migrate (on boot from rc.d, in weekly mails, ...). If we have both information available (old from the kernel transition code) and new we could even provide a script to do it. The reason we might not want to do it automatically is that if the user will decide to boot kernel.old because the new kernel panics after 2 days, she'll be facing the new ada entries in fstab with an 8.x kernel and that would not work either. So it's a decision users need to make eventually themselves during the lifetime of 9.x when upgrading from an older release. > Will such solution be acceptable? I think any solution will be acceptable if it (mostly) works and gets the possible fallout rate (significantly) down and thanks a lot for picking it up now! Bjoern PS: And I think you'll find a lot of testers the next days/weeks on current@ when people update their kernels and forgot to read UPDATING or fail to do the conversion properly.;) -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family.