Date: Sun, 24 Apr 2011 22:59:14 -0600 From: Warner Losh <imp@bsdimp.com> To: Alexander Motin <mav@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, "Bjoern A. Zeeb" <bz@freebsd.org>, Robert Watson <rwatson@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: <54259D19-F41D-460A-9016-5189947A6887@bsdimp.com> In-Reply-To: <4DB47CD4.9060300@FreeBSD.org> References: <201104240858.p3O8wwqT024628@svn.freebsd.org> <alpine.BSF.2.00.1104241140070.36270@fledge.watson.org> <4DB441B0.8020906@FreeBSD.org> <CD028561-B550-4896-BE65-7C827BE6A34A@FreeBSD.org> <4DB47CD4.9060300@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?54259D19-F41D-460A-9016-5189947A6887>