From owner-svn-src-head@FreeBSD.ORG Mon Apr 25 05:01:12 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 A536A1065783; Mon, 25 Apr 2011 05:01:12 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 3286E8FC08; Mon, 25 Apr 2011 05:01:06 +0000 (UTC) Received: from 63.imp.bsdimp.com (63.imp.bsdimp.com [10.0.0.63]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id p3P4xEGC015990 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Sun, 24 Apr 2011 22:59:15 -0600 (MDT) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <4DB47CD4.9060300@FreeBSD.org> Date: Sun, 24 Apr 2011 22:59:14 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <54259D19-F41D-460A-9016-5189947A6887@bsdimp.com> References: <201104240858.p3O8wwqT024628@svn.freebsd.org> <4DB441B0.8020906@FreeBSD.org> <4DB47CD4.9060300@FreeBSD.org> To: Alexander Motin X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Sun, 24 Apr 2011 22:59:15 -0600 (MDT) Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, "Bjoern A. Zeeb" , Robert Watson , 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: Mon, 25 Apr 2011 05:01:12 -0000 Now that the horse is out of the barn, the following might be a little = late (unless we unpull the trigger for a month). But what if we warned that / was on a device name, and not on a 'named' = device. Complain if it was on /dev/da0, but not if it was on = /dev/ufs/fred-root. Users would see this warning and react. Next best thing: make installkernel check for devices on /dev/adX and = refuse to install the kernel if they are (unless REALLY_THIS_IS_RIGHT is = defined :). This won't help the binary upgrader, but will prevent massive = footshooting in the mean time. Warner On Apr 24, 2011, at 1:41 PM, Alexander Motin wrote: > On 24.04.2011 21:59, Bjoern A. Zeeb wrote: >>> 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. >>=20 >> 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)? >=20 > Devfs links won't help users with hardcoded provider names in gmirror, = etc -- from GEOM PoV there will be no such providers. Also to create = proper mapping that module should have real-time information from CAM = about ATA controller details. And looking that it will have to link in = real time any derivative providers also (ad4s1a -> ada0s1a) I worry if = it is possible at all. Some devfs expert needed here. >=20 >>> 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. >>=20 >> 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?). >=20 > I wouldn't like to keep that ugly numbering on by default till the 9.x = EoL even for new installations. Also remember about number of people = already using new ATA, for whom requirement to disable that tunable may = also be uncomfortable. >=20 >> 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, ...). >=20 > It would be fine if it was just devfs noise, but I have some doubts = about it (above). >=20 >> If we have both information available (old from the kernel transition = code) >> and new we could even provide a script to do it. >>=20 >> 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. >=20 > Reasonable. >=20 >>> Will such solution be acceptable? >>=20 >> 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! >=20 > But that solution should not include setting tunables before = upgrading? Can't we teach mergemaster or whatever else to set it = depending on whet disks are now present in system? >=20 >> 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.;) >=20 > I can always say: "read UPDATING" (for log: I am not completely = serious here. :)). >=20 > --=20 > Alexander Motin >=20 >=20