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.
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)?
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.
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?).
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.
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, ...).
It would be fine if it was just devfs noise, but I have some doubts
about it (above).
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.
Reasonable.
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!
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?
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.;)
I can always say: "read UPDATING" (for log: I am not completely serious
here. :)).
--
Alexander Motin
_______________________________________________
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
