On Mon, Apr 25, 2011 at 08:34:33PM +0300, Alexander Motin wrote:
I've thought about the process of fixing hardcoded provider names there,
and it is absolutely not trivial. If we take the symlinking way (patch
is already posted to current@), I think it will be much easier for
everybody, and
On Mon, Apr 25, 2011 at 12:16:22PM -0700, Garrett Cooper wrote:
I'd prefer having an UPDATING note with all of the affected areas so that
people can understand what needs to change and adjust their systems
accordingly. As far as geom based hardcoding is concerned: maybe this can
serve as a
On 26.04.2011 10:00, Pawel Jakub Dawidek wrote:
On Mon, Apr 25, 2011 at 08:34:33PM +0300, Alexander Motin wrote:
I've thought about the process of fixing hardcoded provider names there,
and it is absolutely not trivial. If we take the symlinking way (patch
is already posted to current@), I
On Tue, Apr 26, 2011 at 10:19:55AM +0300, Alexander Motin wrote:
On 26.04.2011 10:00, Pawel Jakub Dawidek wrote:
On Mon, Apr 25, 2011 at 08:34:33PM +0300, Alexander Motin wrote:
I've thought about the process of fixing hardcoded provider names there,
and it is absolutely not trivial. If we
On 26.04.2011 10:35, Pawel Jakub Dawidek wrote:
On Tue, Apr 26, 2011 at 10:19:55AM +0300, Alexander Motin wrote:
On 26.04.2011 10:00, Pawel Jakub Dawidek wrote:
On Mon, Apr 25, 2011 at 08:34:33PM +0300, Alexander Motin wrote:
I've thought about the process of fixing hardcoded provider names
On Tue, Apr 26, 2011 at 10:50:17AM +0300, Alexander Motin wrote:
On 26.04.2011 10:35, Pawel Jakub Dawidek wrote:
On Tue, Apr 26, 2011 at 10:19:55AM +0300, Alexander Motin wrote:
On 26.04.2011 10:00, Pawel Jakub Dawidek wrote:
On Mon, Apr 25, 2011 at 08:34:33PM +0300, Alexander Motin wrote:
On 26.04.2011 11:02, Pawel Jakub Dawidek wrote:
Now, what about fstab? There is a problem to figure out which disk we
booted from once we enter the kernel. I was wondering if we could detect
that someone is trying to mount root which from 'ad[0-9]+X' and
then we could scan all ada[0-9]+X
On Tue, Apr 26, 2011 at 11:18:06AM +0300, Alexander Motin wrote:
What do you think about this:
http://docs.freebsd.org/cgi/mid.cgi?4DB54BA9.5050901
? I've found that zpool utility don't likes symbolic links, but
except this and together with fixing hardcoding problem IMHO it
looks not bad.
On 26.04.2011 11:34, Pawel Jakub Dawidek wrote:
On Tue, Apr 26, 2011 at 11:18:06AM +0300, Alexander Motin wrote:
What do you think about this:
http://docs.freebsd.org/cgi/mid.cgi?4DB54BA9.5050901
? I've found that zpool utility don't likes symbolic links, but
except this and together with
On Tue, Apr 26, 2011 at 11:45:37AM +0300, Alexander Motin wrote:
On 26.04.2011 11:34, Pawel Jakub Dawidek wrote:
On Tue, Apr 26, 2011 at 11:18:06AM +0300, Alexander Motin wrote:
What do you think about this:
http://docs.freebsd.org/cgi/mid.cgi?4DB54BA9.5050901
? I've found that zpool utility
On Sun, Apr 24, 2011 at 06:59:40PM +, Bjoern A. Zeeb wrote:
I had been pondering devfs links 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
On Apr 25, 2011, at 7:45 AM, Pawel Jakub Dawidek wrote:
On Sun, Apr 24, 2011 at 06:59:40PM +, Bjoern A. Zeeb wrote:
I had been pondering devfs links 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
Warner Losh wrote:
On Apr 25, 2011, at 7:45 AM, Pawel Jakub Dawidek wrote:
On Sun, Apr 24, 2011 at 06:59:40PM +, Bjoern A. Zeeb wrote:
I had been pondering devfs links myself, the problem is that from the rc
framework they come too late. If you can add a simple .ko that does it
On Apr 25, 2011, at 10:29 AM, Alexander Motin wrote:
Warner Losh wrote:
On Apr 25, 2011, at 7:45 AM, Pawel Jakub Dawidek wrote:
On Sun, Apr 24, 2011 at 06:59:40PM +, Bjoern A. Zeeb wrote:
I had been pondering devfs links myself, the problem is that from the rc
framework they come too
Warner Losh wrote:
On Apr 25, 2011, at 10:29 AM, Alexander Motin wrote:
Warner Losh wrote:
On Apr 25, 2011, at 7:45 AM, Pawel Jakub Dawidek wrote:
On Sun, Apr 24, 2011 at 06:59:40PM +, Bjoern A. Zeeb wrote:
I had been pondering devfs links myself, the problem is that from the rc
On Sunday, April 24, 2011 3:41:08 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
On Sun, Apr 24, 2011 at 08:58:58AM +, Alexander Motin wrote:
Log:
Switch the GENERIC kernels for all architectures to the new CAM-based ATA
stack. It means that all legacy ATA drivers are disabled and replaced by
respective CAM drivers. If you are using ATA device names in /etc/fstab
On Apr 25, 2011, at 9:29 AM, Alexander Motin m...@freebsd.org wrote:
Warner Losh wrote:
On Apr 25, 2011, at 7:45 AM, Pawel Jakub Dawidek wrote:
On Sun, Apr 24, 2011 at 06:59:40PM +, Bjoern A. Zeeb wrote:
I had been pondering devfs links myself, the problem is that from the rc
framework
David O'Brien wrote:
On Sun, Apr 24, 2011 at 08:58:58AM +, Alexander Motin wrote:
Log:
Switch the GENERIC kernels for all architectures to the new CAM-based ATA
stack. It means that all legacy ATA drivers are disabled and replaced by
respective CAM drivers. If you are using ATA
On Apr 25, 2011, at 1:16 PM, Garrett Cooper wrote:
On Apr 25, 2011, at 9:29 AM, Alexander Motin m...@freebsd.org wrote:
Warner Losh wrote:
On Apr 25, 2011, at 7:45 AM, Pawel Jakub Dawidek wrote:
On Sun, Apr 24, 2011 at 06:59:40PM +, Bjoern A. Zeeb wrote:
I had been pondering devfs
Author: mav
Date: Sun Apr 24 08:58:58 2011
New Revision: 220982
URL: http://svn.freebsd.org/changeset/base/220982
Log:
Switch the GENERIC kernels for all architectures to the new CAM-based ATA
stack. It means that all legacy ATA drivers are disabled and replaced by
respective CAM drivers.
On Sun, 24 Apr 2011 08:58:58 + (UTC)
Alexander Motin m...@freebsd.org wrote:
If you are using ATA
device names in /etc/fstab or other places, make sure to update them
respectively (adX - adaY, acdX - cdY, afdX - daY, astX - saY,
where 'Y's are the sequential numbers for each type in order
On 24.04.2011 12:06, Bruce Cran wrote:
On Sun, 24 Apr 2011 08:58:58 + (UTC)
Alexander Motinm...@freebsd.org wrote:
If you are using ATA
device names in /etc/fstab or other places, make sure to update them
respectively (adX - adaY, acdX - cdY, afdX - daY, astX - saY,
where 'Y's are the
On Sun, 24 Apr 2011 12:15:51 +0300
Alexander Motin m...@freebsd.org wrote:
On 24.04.2011 12:06, Bruce Cran wrote:
People might expect that if ata(4) numbering starts with ad4, ada4
would be created. However on my machines I've seen ad4 get mapped to
ada0.
Yes. With sequential I mean
On Sun, Apr 24, 2011 at 08:58:58AM +, Alexander Motin wrote:
Author: mav
Date: Sun Apr 24 08:58:58 2011
New Revision: 220982
URL: http://svn.freebsd.org/changeset/base/220982
Log:
Switch the GENERIC kernels for all architectures to the new CAM-based ATA
stack. It means that all
On 24.04.2011 13:07, Kostik Belousov wrote:
On Sun, Apr 24, 2011 at 08:58:58AM +, Alexander Motin wrote:
Author: mav
Date: Sun Apr 24 08:58:58 2011
New Revision: 220982
URL: http://svn.freebsd.org/changeset/base/220982
Log:
Switch the GENERIC kernels for all architectures to the new
On Apr 24, 2011, at 8:58 AM, Alexander Motin wrote:
Author: mav
Date: Sun Apr 24 08:58:58 2011
New Revision: 220982
URL: http://svn.freebsd.org/changeset/base/220982
Log:
Switch the GENERIC kernels for all architectures to the new CAM-based ATA
stack. It means that all legacy ATA
On Sun, 24 Apr 2011, Alexander Motin wrote:
Author: mav
Date: Sun Apr 24 08:58:58 2011
New Revision: 220982
URL: http://svn.freebsd.org/changeset/base/220982
Log:
Switch the GENERIC kernels for all architectures to the new CAM-based ATA
stack. It means that all legacy ATA drivers are
On 24.04.2011 13:20, Bjoern A. Zeeb wrote:
On Apr 24, 2011, at 8:58 AM, Alexander Motin wrote:
Author: mav
Date: Sun Apr 24 08:58:58 2011
New Revision: 220982
URL: http://svn.freebsd.org/changeset/base/220982
Log:
Switch the GENERIC kernels for all architectures to the new CAM-based ATA
On Sun, 24 Apr 2011, Alexander Motin wrote:
Are you going to address that on updating magic will make it work within
the next 2-4 weeks?
s/ad[0-9]+/ada0/ should fit 90%. A bit more sophisticated script should fit
most. In what place should I put that magic?
If you will not then thanks for
On Sun, 24 Apr 2011, Robert Watson wrote:
I agree with Bjoern that it is critical to address these issues in a timely
manner -- our users depend on reliable and easy upgrades, and it seems (on
face value) that significant work remains to be done to make that possible.
Our release is
On 24.04.2011 14:00, Robert Watson wrote:
On Sun, 24 Apr 2011, Alexander Motin wrote:
Are you going to address that on updating magic will make it work
within the next 2-4 weeks?
s/ad[0-9]+/ada0/ should fit 90%. A bit more sophisticated script
should fit most. In what place should I put that
Robert Watson wrote:
I'm very pleased to see a continued movement towards the new ATA code;
it offers clear benefits to all of our users, and is definitely
something we want done for 9.0.
Could you say more about the migration strategy for users? I recall
that when you proposed throwing
On Sun, Apr 24, 2011 at 06:28:48PM +0300, Alexander Motin 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.
Speaking on
On 24 Apr 2011, at 17:32, Alexey Dokuchaev wrote:
On Sun, Apr 24, 2011 at 06:28:48PM +0300, Alexander Motin 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
On 24 Apr 2011, at 12:49, Alexander Motin wrote:
Reverting is not an option. _Constructive_ propositions are welcome.
It is the policy of this project that the release engineering team has
final authority over what ships in a release. It is entirely within
scope to revert this change for
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
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 links
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
39 matches
Mail list logo
