Date: Sun, 24 Apr 2011 18:59:40 +0000 From: "Bjoern A. Zeeb" <bz@FreeBSD.org> To: Alexander Motin <mav@FreeBSD.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Robert Watson <rwatson@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: <CD028561-B550-4896-BE65-7C827BE6A34A@FreeBSD.org> In-Reply-To: <4DB441B0.8020906@FreeBSD.org> References: <201104240858.p3O8wwqT024628@svn.freebsd.org> <alpine.BSF.2.00.1104241140070.36270@fledge.watson.org> <4DB441B0.8020906@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CD028561-B550-4896-BE65-7C827BE6A34A>