In message <[EMAIL PROTECTED]>, Poul-Henning Kamp writes:
>Make that _three_ bugs: vinum opens devices directly at the cdevsw
>level, bypassing in the process the vnodes and specfs.
Here is a patch that makes it use vn_open/vn_close/VOP_IOCTL,
bringing it much closer to the way ccd(4) does thing
In message <[EMAIL PROTECTED]>, "Greg 'groggy' Lehey"
writes:
>I don't know how GEOM handles disk labels, though we've heard a lot
>about changes. It's possible that this code is now completely
>redundant. It's preparing to write at offset 8 sectors and on from
>the beginning of the partition;
In message <[EMAIL PROTECTED]>, Ian Dowse writes:
>In message <[EMAIL PROTECTED]>, Robe
>rt Watson writes:
>>However, here's a patch that makes Vinum use namei() to rely on devfs to
>>locate requested devices instead of parsing the device name and guessing
>>the device number (incorrectly with GEO
On Saturday, 5 October 2002 at 4:08:19 +0100, Ian Dowse wrote:
>
> [CCs trimmed]
>
>> The divide by zero problem seems to be caused by an interaction
>> between two bugs: GEOM refuses to return the sector size because
> ...
>> The next failure I get is:
>>
>> Can't write config to /dev/da1s
On Sat, 5 Oct 2002, Ian Dowse wrote:
> >The divide by zero problem seems to be caused by an interaction
> >between two bugs: GEOM refuses to return the sector size because
> ...
> >The next failure I get is:
> >
> > Can't write config to /dev/da1s1d, error 45 (EOPNOTSUPP)
>
> This turns out
On Saturday, 5 October 2002 at 4:08:19 +0100, Ian Dowse wrote:
>
> [CCs trimmed]
>
>> The divide by zero problem seems to be caused by an interaction
>> between two bugs: GEOM refuses to return the sector size because
> ...
>> The next failure I get is:
>>
>> Can't write config to /dev/da1s
On Sat, 5 Oct 2002, Ian Dowse wrote:
> >The divide by zero problem seems to be caused by an interaction
> >between two bugs: GEOM refuses to return the sector size because
> ...
> >The next failure I get is:
> >
> > Can't write config to /dev/da1s1d, error 45 (EOPNOTSUPP)
>
> This turns out
[CCs trimmed]
>The divide by zero problem seems to be caused by an interaction
>between two bugs: GEOM refuses to return the sector size because
...
>The next failure I get is:
>
> Can't write config to /dev/da1s1d, error 45 (EOPNOTSUPP)
This turns out to be vinum doing a DIOCWLABEL to ma
In message <[EMAIL PROTECTED]>, Robe
rt Watson writes:
>However, here's a patch that makes Vinum use namei() to rely on devfs to
>locate requested devices instead of parsing the device name and guessing
>the device number (incorrectly with GEOM). Unfortunately, I almost
>immediately run into a di
* De: Julian Elischer <[EMAIL PROTECTED]> [ Data: 2002-10-04 ]
[ Subjecte: Re: [ GEOM tests ] disklabel warnings and vinum drives lost ]
>
>
> On Fri, 4 Oct 2002, Robert Watson wrote:
>
> > On the general topic of access to devices before a root has been f
On Friday, 4 October 2002 at 20:29:51 -0400, Robert Watson wrote:
>
> On Sat, 5 Oct 2002, Greg 'groggy' Lehey wrote:
>
>> FWIW, I've never seen this code. The dates on the patch suggest that
>> it was made in the last quarter of an hour:
>
> I didn't claim that this was his code. This was code
On Fri, 4 Oct 2002, Robert Watson wrote:
> On the general topic of access to devices before a root has been found,
> Maxime Henrion <[EMAIL PROTECTED]> has done some interesting work on
> 'rootfs', a pseudofs used to bootstrap support for devfs, etc. In such an
> environment, Vinum and other c
On Sat, 5 Oct 2002, Greg 'groggy' Lehey wrote:
> FWIW, I've never seen this code. The dates on the patch suggest that
> it was made in the last quarter of an hour:
I didn't claim that this was his code. This was code I just wrote to
address Vinum not finding the devices due to major/minor num
On Friday, 4 October 2002 at 20:21:29 -0400, Robert Watson wrote:
>
> On Fri, 4 Oct 2002, Robert Watson wrote:
>
>> On Fri, 4 Oct 2002, Terry Lambert wrote:
>>
>>> The assumption here is that the devfs will be available to the system
>>> before the root is mounted transparently over it. This is
Greg 'groggy' Lehey wrote:
> On Friday, 4 October 2002 at 16:03:24 -0700, Peter Wemm wrote:
> > Terry Lambert wrote:
> >> Emiel Kollof wrote:
> >>> * Peter Wemm ([EMAIL PROTECTED]) wrote:
> vinum is so much unbelievable stuff in it. Consider this stuff:
>
> sys/dev/vinum/vinumio.c
On Friday, 4 October 2002 at 20:07:11 -0400, Robert Watson wrote:
>
> On Fri, 4 Oct 2002, Terry Lambert wrote:
>
>> The assumption here is that the devfs will be available to the system
>> before the root is mounted transparently over it. This is also doable
>> with an unmounted instance of the
On Fri, 4 Oct 2002, Robert Watson wrote:
> On Fri, 4 Oct 2002, Terry Lambert wrote:
>
> > The assumption here is that the devfs will be available to the system
> > before the root is mounted transparently over it. This is also doable
> > with an unmounted instance of the backing devfs, not yet
On Friday, 4 October 2002 at 16:03:24 -0700, Peter Wemm wrote:
> Terry Lambert wrote:
>> Emiel Kollof wrote:
>>> * Peter Wemm ([EMAIL PROTECTED]) wrote:
vinum is so much unbelievable stuff in it. Consider this stuff:
sys/dev/vinum/vinumio.c:
>>
>> [ ... ]
>>
This crud has *go
On Friday, 4 October 2002 at 14:11:57 -0700, Peter Wemm wrote:
> Poul-Henning Kamp wrote:
>> In message <[EMAIL PROTECTED]>, n0go013 writ
> es
>> :
>>> On 04.10-15:40, fergus wrote:
On 04.10-14:20, Poul-Henning Kamp wrote:
[...]
> I suspect vinum uses this sysctl to get an inven
On Fri, 4 Oct 2002, Terry Lambert wrote:
> The assumption here is that the devfs will be available to the system
> before the root is mounted transparently over it. This is also doable
> with an unmounted instance of the backing devfs, not yet mounted on
> /dev, if a transparent mount of / over
>
> Terry Lambert wrote:
> > Emiel Kollof wrote:
> > > * Peter Wemm ([EMAIL PROTECTED]) wrote:
> > > > vinum is so much unbelievable stuff in it. Consider this stuff:
> > > >
> > > > sys/dev/vinum/vinumio.c:
> >
> > [ ... ]
> >
> > > > This crud has *got* to be taken out and shot, then
> rewo
On Fri, 4 Oct 2002, Terry Lambert wrote:
> I think the major problem with the Vinum code is that it isn't
> very readable in an 80 column editor window with 8 column tabs,
> but that's pretty much the worst you can say about it, other than
> the code has not been maintained by the people changing
Terry Lambert wrote:
> Emiel Kollof wrote:
> > * Peter Wemm ([EMAIL PROTECTED]) wrote:
> > > vinum is so much unbelievable stuff in it. Consider this stuff:
> > >
> > > sys/dev/vinum/vinumio.c:
>
> [ ... ]
>
> > > This crud has *got* to be taken out and shot, then reworked to do it
> > > proper
Emiel Kollof wrote:
> * Peter Wemm ([EMAIL PROTECTED]) wrote:
> > vinum is so much unbelievable stuff in it. Consider this stuff:
> >
> > sys/dev/vinum/vinumio.c:
[ ... ]
> > This crud has *got* to be taken out and shot, then reworked to do it
> > properly.
>
> Amen! (and no, I'm not volunteer
* Peter Wemm ([EMAIL PROTECTED]) wrote:
> vinum is so much unbelievable stuff in it. Consider this stuff:
>
> sys/dev/vinum/vinumio.c:
>
[Big ugly if/else fallthrough snipped]
Ick... Which sick person wrote that? switch() and cpp macros usually do
wonders in cases like these in terms of
Poul-Henning Kamp wrote:
> In message <[EMAIL PROTECTED]>, n0go013 writ
es
> :
> >On 04.10-15:40, fergus wrote:
> >> On 04.10-14:20, Poul-Henning Kamp wrote:
> >> [...]
> >> > I suspect vinum uses this sysctl to get an inventory of disks in
> >> > the system, so can I get you to try again maki
In message <[EMAIL PROTECTED]>, n0go013 writes
:
>On 04.10-15:40, fergus wrote:
>> On 04.10-14:20, Poul-Henning Kamp wrote:
>> [...]
>> > I suspect vinum uses this sysctl to get an inventory of disks in
>> > the system, so can I get you to try again making sure you have
>> > rev. 1.20 of src/sys/g
On 04.10-15:40, fergus wrote:
> On 04.10-14:20, Poul-Henning Kamp wrote:
> [...]
> > I suspect vinum uses this sysctl to get an inventory of disks in
> > the system, so can I get you to try again making sure you have
> > rev. 1.20 of src/sys/geom/geom_disk.c ?
[...]
> i'll let you know the test re
On 04.10-14:20, Poul-Henning Kamp wrote:
> I suspect vinum uses this sysctl to get an inventory of disks in
> the system, so can I get you to try again making sure you have
> rev. 1.20 of src/sys/geom/geom_disk.c ?
still in the middle of the build but i don't think so -- it looks like
vinum is us
In message <[EMAIL PROTECTED]>, n0go013 writes:
>rebuilt kernel with GEOM and everything is ok but disklabel now dumps a
>warning message for each undefined partition. should these be manually
>initialised to valid entries or is this a bug ?
>
>more importantly vinum can no longer find the drives
rebuilt kernel with GEOM and everything is ok but disklabel now dumps a
warning message for each undefined partition. should these be manually
initialised to valid entries or is this a bug ?
more importantly vinum can no longer find the drives but i'm not sure
thats related as cvsup was from 200
31 matches
Mail list logo
