On Sunday 23 November 2003 23:50, you wrote:
>
> Yes. The fix wasn't enough. I was holding off committing until I
> could test it.
Thanks for YOUR commit! :-) All works fine here now...
--
Ciao/BSD - Matthias
Matthias Schuendehuette , Berlin (Germany)
PGP-Key at and ID: 0xDDFB0A5F
_
On Sunday, 23 November 2003 at 22:46:30 +0100, Matthias Schuendehuette wrote:
> Hello,
>
> I just built a new world+kernel after the commit of grogs corrections
> but I still get:
>
> [EMAIL PROTECTED] - ~
> 503 # vinum start
> ** no drives found: No such file or directory
Yes. The fix wasn't eno
Hi Greg,
On Sat, Nov 22, 2003 at 11:05:38AM +1030, Greg 'groggy' Lehey wrote:
> On Friday, 21 November 2003 at 15:42:12 -0800, Marcus Reid wrote:
> > Hello,
> >
> > I just upgraded a -CURRENT box this afternoon to discover that vinum
> > is broken. If I hadn't done dumps of my working world before
On Friday, 21 November 2003 at 15:42:12 -0800, Marcus Reid wrote:
> Hello,
>
> I just upgraded a -CURRENT box this afternoon to discover that vinum
> is broken. If I hadn't done dumps of my working world beforehand I
> would be in pretty sad shape. Should UPDATING make note of this
> breakage?
No.
Any more word on this?
I haven't tried creating a new volume to see if it
will create because i don't want to loose wants
currently there.
Not trying to harrass anyone, just checking :).
Daryl
--- Robert Watson <[EMAIL PROTECTED]> wrote:
>
> On Fri, 17 Jan 2003, Eric Anholt wrote:
>
> > I'm g
On Fri, 17 Jan 2003, Eric Anholt wrote:
> I'm getting the same (no drives/subdisks/plexes/volumes found) trying to
> upgrade from a Nov 11 kernel/userland to Nov 16th kernel. I tried
> seeing if using a Nov 16th vinum binary would load them, but after doing
> a stop/start, the system paniced, an
On Sun, 2003-11-16 at 20:14, Daryl Chance wrote:
> I am currently not able to load my vinum array
> (haven't tried to revert back to pre-statfs source)
> after I built a new kernel and world. I upgraded the
> recommended way (installkernel, reboot, single user
> mode, installworld, etc) and when m
At Sun, 16 Nov 2003 20:14:24 -0800 (PST),
Daryl Chance wrote:
> I am currently not able to load my vinum array
> (haven't tried to revert back to pre-statfs source)
Me too.
After upgrading the kernel from -current as of mid september to
today's, I rebooted and got "vinum loaded, no drives found" m
Hello,
On 13.11.2003 at 16:33 cosmin wrote:
Hello, I'm having major problems with the latest kernel sources and
vinum. I don't really know where to begin the debug. For now, I'll
have to run older sources just to have vinum working.
Vinum isn't able to detect my volume, even though it work
Greg 'groggy' Lehey wrote:
On Tuesday, 5 August 2003 at 22:21:41 +0200, Rob wrote:
Poul-Henning Kamp wrote:
In message <[EMAIL PROTECTED]>, Rob writes:
Hi all,
After cvs'upping (about 12 hours ago) and building world/kernel vinum
stopped working. It does show my two disks but nothing more. I
On Tuesday, 5 August 2003 at 22:21:41 +0200, Rob wrote:
> Poul-Henning Kamp wrote:
>> In message <[EMAIL PROTECTED]>, Rob writes:
>>
>>> Hi all,
>>>
>>> After cvs'upping (about 12 hours ago) and building world/kernel vinum
>>> stopped working. It does show my two disks but nothing more. I also
>>>
Kamp" <[EMAIL PROTECTED]>
To: "Aaron Wohl" <[EMAIL PROTECTED]>
Date: Fri, 08 Aug 2003 15:24:09 +0200
Subject: Re: vinum lock panic at startup -current
In message <[EMAIL PROTECTED]>, "Aaron Wohl"
writes:
> Panicstring: mutex Giant owned at /usr/src/sy
Poul-Henning Kamp wrote:
In message <[EMAIL PROTECTED]>, Rob writes:
Hi all,
After cvs'upping (about 12 hours ago) and building world/kernel vinum
stopped working. It does show my two disks but nothing more. I also
get an error message right after the bootloader:
Can you try this patch:
Inde
In message <[EMAIL PROTECTED]>, "Aaron Wohl" writes:
> Panicstring: mutex Giant owned at /usr/src/sys/geom/geom_dev.c:198
Ok, then I think I know what it is.
Vinum appearantly does not go through SPECFS but rather calls into
the disk device drivers directly. That is a pretty wrong thing to
do,
In message <[EMAIL PROTECTED]>, "Aaron Wohl" writes:
>I just cvsuped -current this afternoon to get about 1 weeks updates.
>After that the kernel panics booting starting vinum. I removed the one
>vinum volume (reformated as UFS2) I had for testing. And it still panics.
> I changed the /etc/rc.con
On Fri, Aug 08, 2003 at 10:22:06AM +0200, Poul-Henning Kamp wrote:
> In message <[EMAIL PROTECTED]>, "Aaron Wohl" writes:
> >I just cvsuped -current this afternoon to get about 1 weeks updates.
> >After that the kernel panics booting starting vinum. I removed the one
> >vinum volume (reformated a
On Thursday, 7 August 2003 at 18:23:10 -0600, Aaron Wohl wrote:
> I just cvsuped -current this afternoon to get about 1 weeks updates.
> After that the kernel panics booting starting vinum. I removed the one
> vinum volume (reformated as UFS2) I had for testing. And it still panics.
> I changed
On Friday, 8 August 2003 at 16:04:05 +0200, Rob wrote:
> Greg 'groggy' Lehey wrote:
>> On Tuesday, 5 August 2003 at 22:21:41 +0200, Rob wrote:
>>> Poul-Henning Kamp wrote:
In message <[EMAIL PROTECTED]>, Rob writes:
> Hi all,
>
> After cvs'upping (about 12 hours ago) and bui
I tried it this morning on different systems. So far the two AMD systems
panic with vinum start and the intel/p4 works ok. All systems have no
vinum volumes currently.
Good dump found on device /dev/ad0s1b
Architecture: i386
Architecture version: 1
Dump length: 1073676288B (1023 MB)
Bloc
On Friday, 8 August 2003 at 10:27:31 +0200, Erwin Lansing wrote:
> On Fri, Aug 08, 2003 at 10:22:06AM +0200, Poul-Henning Kamp wrote:
>> In message <[EMAIL PROTECTED]>, "Aaron Wohl" writes:
>>> I just cvsuped -current this afternoon to get about 1 weeks updates.
>>> After that the kernel panics bo
In message <[EMAIL PROTECTED]>, Rob writes:
>Hi all,
>
>After cvs'upping (about 12 hours ago) and building world/kernel vinum
>stopped working. It does show my two disks but nothing more. I also
>get an error message right after the bootloader:
Can you try this patch:
Index: spec_vnops.c
=
--On 2. august 2003 11:16 +0200 Bernd Walter <[EMAIL PROTECTED]>
wrote:
Looks like a problem in vinum. The other backtrace was the same, right?
Please take a look at an older thread named (IIRC) vinum or geom bug?
Greg asked for special debug output, but it never happened again for me.
A real mur
[Sending to [EMAIL PROTECTED], and Kris copied in Greg so I'll also do that]
--On 2. august 2003 02:00 -0700 Kris Kennaway <[EMAIL PROTECTED]> wrote:
db> trace
g_dev_strategy(c2156024,c2153800,0,cfb528d0,c2099eca) at
g_dev_strategy+0x29 launch_requests(c299bf00,0,1,,47) at
launch_reque
On Sat, Aug 02, 2003 at 02:00:52AM -0700, Kris Kennaway wrote:
> On Sat, Aug 02, 2003 at 10:11:24AM +0200, Eivind Olsen wrote:
>
> > db> trace
> > g_dev_strategy(c2156024,c2153800,0,cfb528d0,c2099eca) at g_dev_strategy+0x29
> > launch_requests(c299bf00,0,1,,47) at launch_requests+0x448
On Sat, Jun 14, 2003 at 03:15:27PM +0930, Greg 'groggy' Lehey wrote:
> On Tuesday, 10 June 2003 at 14:05:11 +0200, Bernd Walter wrote:
> >
> > fatal kernel trap:
> >
> > Stopped at g_dev_strategy+0x44:stq t0,0x20(v0) <0x20>
> >
> > db> trace
> > g_dev_strategy() at g_dev_strateg
On Tuesday, 10 June 2003 at 14:05:11 +0200, Bernd Walter wrote:
>
> fatal kernel trap:
>
> Stopped at g_dev_strategy+0x44:stq t0,0x20(v0) <0x20>
>
> db> trace
> g_dev_strategy() at g_dev_strategy+0x44
> launch_requests() at launch_requests+0x390
> prologue botch: displacement 12
On Tue, 25 Mar 2003, Kenneth D. Merry wrote:
KDM>On Wed, Mar 26, 2003 at 11:06:52 +1030, Greg 'groggy' Lehey wrote:
KDM>> On Tuesday, 25 March 2003 at 18:44:03 +0100, Hartmut Brandt wrote:
KDM>> >
KDM>> > Hi,
KDM>> >
KDM>> > when calling 'vinum start' it responds with
KDM>> >
KDM>> > usage: read d
On Wed, Mar 26, 2003 at 11:06:52 +1030, Greg 'groggy' Lehey wrote:
> On Tuesday, 25 March 2003 at 18:44:03 +0100, Hartmut Brandt wrote:
> >
> > Hi,
> >
> > when calling 'vinum start' it responds with
> >
> > usage: read drive [drive ...]
> >
> > from looking at the code, it appears that it cannot f
On Tuesday, 25 March 2003 at 18:44:03 +0100, Hartmut Brandt wrote:
>
> Hi,
>
> when calling 'vinum start' it responds with
>
> usage: read drive [drive ...]
>
> from looking at the code, it appears that it cannot find the disk drives
> to read the configuration from.
>
> vinum read da0 da1
>
> just
On Sun, Mar 16, 2003 at 09:20:10AM +1030, Greg 'groggy' Lehey
<[EMAIL PROTECTED]> wrote:
> >>> Will it suffice to switch off power for one disk to simulate "more"
> >>> real-world disk failure? Are there any hidden pitfalls for failing
> >>> and restoring operation of non-hotswap disks?
> >>
> >>
On Saturday, 15 March 2003 at 23:56:24 +0100, Poul-Henning Kamp wrote:
> In message <[EMAIL PROTECTED]>, "Greg 'groggy' Lehey"
> writes:
>
>>> Ok, I'll try to simulate the disk failure by switching off the
>>> power, then.
>>
>> I think you misunderstand. I simulated the disk failures by doing a
In message <[EMAIL PROTECTED]>, "Greg 'groggy' Lehey"
writes:
>> Ok, I'll try to simulate the disk failure by switching off the
>> power, then.
>
>I think you misunderstand. I simulated the disk failures by doing a
>"stop -f". I can't see any way that the way they go down can
>influence the rev
On Saturday, 15 March 2003 at 10:34:54 +0200, Vallo Kallaste wrote:
> On Sat, Mar 15, 2003 at 12:02:23PM +1030, Greg 'groggy' Lehey
> <[EMAIL PROTECTED]> wrote:
>
>>> -current, system did panic everytime at the end of
>>> initialisation of parity (raidctl -iv raid?). So I used the
>>> raidframe pat
On Sat, Mar 15, 2003 at 12:02:23PM +1030, Greg 'groggy' Lehey
<[EMAIL PROTECTED]> wrote:
> > -current, system did panic everytime at the end of
> > initialisation of parity (raidctl -iv raid?). So I used the
> > raidframe patch for -stable at
> > http://people.freebsd.org/~scottl/rf/2001-08-28-RAI
On Friday, 14 March 2003 at 10:05:28 +0200, Vallo Kallaste wrote:
> On Fri, Mar 14, 2003 at 01:16:02PM +1030, Greg 'groggy' Lehey
> <[EMAIL PROTECTED]> wrote:
>
>>> So I did. Loaned two SCSI disks and 50-pin cable. Things haven't
>>> improved a bit, I'm very sorry to say it.
>>
>> Sorry for the slo
On Fri, Mar 14, 2003 at 01:16:02PM +1030, Greg 'groggy' Lehey
<[EMAIL PROTECTED]> wrote:
> > So I did. Loaned two SCSI disks and 50-pin cable. Things haven't
> > improved a bit, I'm very sorry to say it.
>
> Sorry for the slow reply to this. I thought it would make sense to
> try things out here
On Saturday, 1 March 2003 at 20:43:10 +0200, Vallo Kallaste wrote:
> On Thu, Feb 27, 2003 at 11:53:02AM +0200, Vallo Kallaste wrote:
>
The vinum R5 and system as a whole were stable without
softupdates. Only one problem remained after disabling softupdates,
while being online and u
On Thu, Feb 27, 2003 at 11:53:02AM +0200, Vallo Kallaste wrote:
> > > The vinum R5 and system as a whole were stable without
> > > softupdates. Only one problem remained after disabling softupdates,
> > > while being online and user I/O going on, rebuilding of failed disk
> > > corrupt the R5 vol
On Thu, Feb 27, 2003 at 11:59:59AM +1030, Greg 'groggy' Lehey
<[EMAIL PROTECTED]> wrote:
> > The crashes and anomalies with filesystem residing on R5 volume were
> > related to vinum(R5)/softupdates combo.
>
> Well, at one point we suspected that. But the cases I have seen were
> based on a misa
On Friday, 21 February 2003 at 1:56:56 -0800, Terry Lambert wrote:
> Vallo Kallaste wrote:
>> The crashes and anomalies with filesystem residing on R5 volume were
>> related to vinum(R5)/softupdates combo. The vinum R5 and system as
>> a whole were stable without softupdates. Only one problem rema
On Friday, 21 February 2003 at 10:00:46 +0200, Vallo Kallaste wrote:
> On Thu, Feb 20, 2003 at 02:28:45PM -0800, Darryl Okahata
> <[EMAIL PROTECTED]> wrote:
>
>> Vallo Kallaste <[EMAIL PROTECTED]> wrote:
>>
>>> I'll second Brad's statement about vinum and softupdates
>>> interactions. My last exper
Darryl Okahata wrote:
> Terry Lambert <[EMAIL PROTECTED]> wrote:
> > I think this is an expected problem with a lot of concatenation,
> > whether through Vinum, GEOM, RAIDFrame, or whatever.
> >
> > This comes about for the same reason that you can't "mount -u"
> > to turn Soft Updates from "off" t
Terry Lambert <[EMAIL PROTECTED]> wrote:
> I think this is an expected problem with a lot of concatenation,
> whether through Vinum, GEOM, RAIDFrame, or whatever.
>
> This comes about for the same reason that you can't "mount -u"
> to turn Soft Updates from "off" to "on": Soft Updates does not
>
Vallo Kallaste wrote:
> The crashes and anomalies with filesystem residing on R5 volume were
> related to vinum(R5)/softupdates combo. The vinum R5 and system as
> a whole were stable without softupdates. Only one problem remained
> after disabling softupdates, while being online and user I/O going
On Saturday, 8 February 2003 at 18:34:04 +0100, Michael Reifenberger wrote:
> On Fri, 7 Feb 2003, Michael Reifenberger wrote:
> ...
>>> As a workaround, you can try setting
>>>
>>> vinum_load=YES
>>> vinum.autostart=YES
>>>
>>> in your /boot/loader.conf, /and/ remove the start_vinum line from
>>>
On Saturday, 8 February 2003 at 21:42:27 +0100, Joerg Wunsch wrote:
> As Greg 'groggy' Lehey wrote:
>
>>> I guess it's time to dump the old vinum start code from
>>> vinum(8) completely, and use the in-kernel scan now.
>>
>> This sounds like a good idea.
>
> Not after looking a bit closer. ;-) The
As Greg 'groggy' Lehey wrote:
> > I guess it's time to dump the old vinum start code from
> > vinum(8) completely, and use the in-kernel scan now.
>
> This sounds like a good idea.
Not after looking a bit closer. ;-) The only difference ist that the
userland "vinum start" uses devstat, while the
On Fri, 7 Feb 2003, Michael Reifenberger wrote:
...
> > As a workaround, you can try setting
> >
> > vinum_load=YES
> > vinum.autostart=YES
> >
> > in your /boot/loader.conf, /and/ remove the start_vinum line from
> > rc.conf. Please tell me whether this gives different results.
Bad things happen
On Saturday, 8 February 2003 at 0:00:45 +0100, Joerg Wunsch wrote:
> As Michael Reifenberger wrote:
>
>>> What does your sysctl kern.disks say?
>>
>> (nihil)(root) # sysctl -a kern.disks
>> kern.disks: da1 da0 ad1 ad0
>
> That's OK.
>
> I guess it's time to dump the old vinum start code from
> vi
As Michael Reifenberger wrote:
> > What does your sysctl kern.disks say?
>
> (nihil)(root) # sysctl -a kern.disks
> kern.disks: da1 da0 ad1 ad0
That's OK.
I guess it's time to dump the old vinum start code from
vinum(8) completely, and use the in-kernel scan now.
--
cheers, J"org
On Fri, 7 Feb 2003, Joerg Wunsch wrote:
> Date: Fri, 7 Feb 2003 21:56:45 +0100 (MET)
> From: Joerg Wunsch <[EMAIL PROTECTED]>
> Reply-To: Joerg Wunsch <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Cc: Michael Reifenberger <[EMAIL PROTECTED]>
> Subject: Re: vi
Michael Reifenberger <[EMAIL PROTECTED]> wrote:
> After reboot, a `vinum start` gives me:
> ** no drives found: No such file or directory
Do you perchance have a kernel without GEOM?
vinum start has now been changed to use sysctl kern.disks as the list
of devices to scan. Hmm. No, maybe not...
[EMAIL PROTECTED] (Joerg Wunsch) wrote:
> The biggest problem of all this is, of course, the bootstrapping
> step. The bootstrap still needs an `a' partition in order to read
> at least /boot/loader etc. from. The solution is to produce a faked
> overlay `a' partition that sits at exactly the po
Alex Deiter <[EMAIL PROTECTED]> wrote:
> Say me please, sometime growfs will learn to work with vinum
> volumes?
The growfs maintainers know about the problem, and are working on a
solution. We learned about that problem too late before 5.0R was due,
so since a quick fix couldn't be produced in
Ollivier Robert <[EMAIL PROTECTED]> wrote:
>> Oh, i should add: in my case, it's loaded before mounting the
>> root (root is on vinum).
> And how did you achieved this ? I thought vinum isn't able to do
> that...
Well, the patch for -current is currently only sitting here on my
machine(s). Greg
> I have no possibility to get new large disk now.
> Should I try to remove plex usr.p1 ?
>
Sounds like it's related to a problem I encountered with vinum
some time ago. For me, vinum would bail out in panic if I tried
to access an area of a volume that was not initialized on the
mirrored plex. T
On Thursday, 23 May 2002 at 21:44:52 +0200, yuri khotyaintsev wrote:
> Hi!
>
> I had a vinum mirrored volume usr
> with two plexes usr.p0 and usr.p1, with respective
> subdisks usr.p0.s0 and usr.p1.s0.
>
> So recently one of the disks crashed. I tried to replace the disk with
> another one (which
yuri khotyaintsev <[EMAIL PROTECTED]> wrote:
> so now I have
> usr.p0 -> 1 subdisk (usr.p0.s0)
> usr.p1 -> 0 subdisk
> I have no possibility to get new large disk now.
> Should I try to remove plex usr.p1 ?
Yes, I think so. Perhaps you need to detach it before (most likely).
--
cheers, J"or
In message <[EMAIL PROTECTED]>, "Greg 'groggy' Lehey" w
rites:
>> This is a non-GEOM kernel - GEOM wouldn't even let me disklabel the
>> drives.
>
>That doesn't surprise me. You might ask phk how he proposes to
>address that issue.
This is ongoing work in GEOM.
--
Poul-Henning Kamp | UN
Greg 'groggy' Lehey <[EMAIL PROTECTED]> writes:
> Right. You have created a Vinum drive /dev/da1d, and now you're
> trying to tell Vinum to use /dev/da1.
Uh, thanks.
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current
On Tuesday, 30 April 2002 at 5:46:13 +0200, Dag-Erling Smorgrav wrote:
> On a very recent -CURRENT, I'm unable to create and newfs a vinum
> volume:
>
> #size offsetfstype [fsize bsize bps/cpg]
> c: 83800800unused0 0 # (Cyl.0 - 521*)
> d:
On Mon, Apr 15, 2002 at 04:08:43PM -0500, Patrick Hartling wrote:
> Bernd,
> This sounds very promising, but I want to make sure I do this
> correctly. When you say to remove the plexes, that means to use 'vinum rm'
> with appropriate options, correct? As far as reconfiguring, can I
Bernd,
This sounds very promising, but I want to make sure I do this correctly.
When you say to remove the plexes, that means to use 'vinum rm' with
appropriate options, correct? As far as reconfiguring, can I use the
output from 'vinum printconfig' as the input configuration file?
On Fri, Apr 12, 2002 at 05:46:29PM -0500, Patrick Hartling wrote:
> I suffered a system crash earlier today running -current from April 10.
> I have a Vinum volume set up as a mirror, and during the reboot, I had
> to fsck it. Everything seemed normal (at least that's what I thought),
> but n
On Fri, 12 Apr 2002, Patrick Hartling wrote:
...
> 2 drives:
> D a State: up /dev/da3s1e A: 0/12288 MB (0%)
> D b State: up /dev/da4s1e A: 0/12288 MB (0%)
>
> The fact that it says the drives have 0% used greatly concerns me.
Thats 0% fr
On Sat, Dec 29, 2001 at 04:03:40PM +1030, Greg Lehey wrote:
> On Saturday, 29 December 2001 at 6:21:29 +0100, Bernd Walter wrote:
> > On Sat, Dec 29, 2001 at 10:09:11AM +1030, Greg Lehey wrote:
> >> This has nothing to do with Vinum. The errors are at the device
> >> driver level, and they appea
On Saturday, 29 December 2001 at 6:21:29 +0100, Bernd Walter wrote:
> On Sat, Dec 29, 2001 at 10:09:11AM +1030, Greg Lehey wrote:
>> This has nothing to do with Vinum. The errors are at the device
>> driver level, and they appear to relate only to the compact flash
>> adaptor. Does it work when
On Sat, Dec 29, 2001 at 10:09:11AM +1030, Greg Lehey wrote:
> On Friday, 28 December 2001 at 14:48:54 -0600, Jim Bryant wrote:
> > I know this is probably a minor issue, as it is only an annoyance, and
> > doesn't impact operation or performance, but still..
> >
> > Ever since I concatenated some
On Friday, 28 December 2001 at 14:48:54 -0600, Jim Bryant wrote:
> I know this is probably a minor issue, as it is only an annoyance, and
> doesn't impact operation or performance, but still..
>
> Ever since I concatenated some old drives to make a more reasonable capacity
> out of them, I have be
On Thu, Dec 13, 2001 at 12:47:53PM +1030, Greg Lehey wrote:
> On Thursday, 13 December 2001 at 3:06:14 +0100, Bernd Walter wrote:
> > Currently if we have two writes in two stripes each, all initated before
> > the first finished, the drive has to seek between the two stripes, as
> > the second w
On Thursday, 13 December 2001 at 3:06:14 +0100, Bernd Walter wrote:
> On Thu, Dec 13, 2001 at 10:54:13AM +1030, Greg Lehey wrote:
>> On Wednesday, 12 December 2001 at 12:53:37 +0100, Bernd Walter wrote:
>>> On Wed, Dec 12, 2001 at 04:22:05PM +1030, Greg Lehey wrote:
On Tuesday, 11 December 2
On Thu, Dec 13, 2001 at 10:54:13AM +1030, Greg Lehey wrote:
> On Wednesday, 12 December 2001 at 12:53:37 +0100, Bernd Walter wrote:
> > On Wed, Dec 12, 2001 at 04:22:05PM +1030, Greg Lehey wrote:
> >> On Tuesday, 11 December 2001 at 3:11:21 +0100, Bernd Walter wrote:
> >> 2. Cache the parity blo
On Wednesday, 12 December 2001 at 12:53:37 +0100, Bernd Walter wrote:
> On Wed, Dec 12, 2001 at 04:22:05PM +1030, Greg Lehey wrote:
>> On Tuesday, 11 December 2001 at 3:11:21 +0100, Bernd Walter wrote:
>>> striped:
>>> If you have 512byte stripes and have 2 disks.
>>> You access 64k which is put
On Wed, Dec 12, 2001 at 04:22:05PM +1030, Greg Lehey wrote:
> On Tuesday, 11 December 2001 at 3:11:21 +0100, Bernd Walter wrote:
> > striped:
> > If you have 512byte stripes and have 2 disks.
> > You access 64k which is put into 2 32k transactions onto the disk.
>
> Only if your software optimiz
Alfred Perlstein <[EMAIL PROTECTED]> wrote:
>> ..., I saw a message saying that Vinum was
>> not yet ready for use with DEVFS. Is that still the case?
> I fixed that. :) Let me and Grog know if you have problems.
It basically works for me. Of course, vinum still has a dozen
of bugs that get u
Greg Lehey <[EMAIL PROTECTED]> wrote:
} On Sunday, 1 July 2001 at 14:22:36 -0500, Patrick Hartling wrote:
} > Alfred Perlstein <[EMAIL PROTECTED]> wrote:
} >
} >> * Patrick Hartling <[EMAIL PROTECTED]> [010630 14:04] wrote:
} >>> I just got two new hard drives, and I am preparing to set them up
On Sunday, 1 July 2001 at 14:22:36 -0500, Patrick Hartling wrote:
> Alfred Perlstein <[EMAIL PROTECTED]> wrote:
>
>> * Patrick Hartling <[EMAIL PROTECTED]> [010630 14:04] wrote:
>>> I just got two new hard drives, and I am preparing to set them up to do
>>> RAID-1 with Vinum. A few weeks ago (ar
Alfred Perlstein <[EMAIL PROTECTED]> wrote:
} * Patrick Hartling <[EMAIL PROTECTED]> [010630 14:04] wrote:
} > I just got two new hard drives, and I am preparing to set them up to do
} > RAID-1 with Vinum. A few weeks ago (around the time that use of DEVFS
} > became the default in -current), I
* Patrick Hartling <[EMAIL PROTECTED]> [010630 14:04] wrote:
> I just got two new hard drives, and I am preparing to set them up to do
> RAID-1 with Vinum. A few weeks ago (around the time that use of DEVFS
> became the default in -current), I saw a message saying that Vinum was
> not yet ready f
On Sun, Oct 29, 2000, John W. De Boskey wrote:
> Hi,
>
>I ran into an interesting gotcha with fsck and vinum...
>
>I have the following line in /etc/fstab:
>
> /dev/vinum/raid5/pubufs rw 2 2
>
>and during an upgrade (old current to current
On Sun, 29 Oct 2000, John W. De Boskey wrote:
>I ran into an interesting gotcha with fsck and vinum...
>
>I have the following line in /etc/fstab:
>
> /dev/vinum/raid5/pubufs rw 2 2
>
>and during an upgrade (old current to current), I comm
On Wednesday, 5 April 2000 at 11:43:52 -0700, Matthew Dillon wrote:
>
>>
>>> Also, as a general note to everyone, make sure you are building vinum
>>> into the kernel directly and not using it as a kld, just to ensure that
>>> it stays in sync with the kernel.
>>
>> Isn't this
On Wednesday, 5 April 2000 at 11:42:40 -0700, Matthew Dillon wrote:
>> Matt,
>> help me understand your patch. this is how i read it at this
>> time:
>>
>>
>> Matt has just made available an early patch that corrects the vinum
>> panic. is this the same vinum panic that people are claiming
:
:At 12:21 PM -0700 2000/4/5, Alfred Perlstein wrote:
:
:> Last I checked, doing so is dangerous because by default the userland
:> components of vinum have debugging on which is incompatible with
:> a kernel running vinum without debug (the default when linked in).
:
: Correct, I belie
At 12:21 PM -0700 2000/4/5, Alfred Perlstein wrote:
> Last I checked, doing so is dangerous because by default the userland
> components of vinum have debugging on which is incompatible with
> a kernel running vinum without debug (the default when linked in).
Correct, I believe that t
* Matthew Dillon <[EMAIL PROTECTED]> [000405 12:12] wrote:
>
> :
> :> Also, as a general note to everyone, make sure you are building vinum
> :> into the kernel directly and not using it as a kld, just to ensure that
> :> it stays in sync with the kernel.
> :
> : Isn't this in
At 11:43 AM -0700 2000/4/5, Matthew Dillon wrote:
> This is my personal recommendation - if you are messing around with
> something that is under development or test, it is best to build it
> into the kernel to avoid getting out of sync without knowing it.
Ahh, okay. Soun
:
:> Also, as a general note to everyone, make sure you are building vinum
:> into the kernel directly and not using it as a kld, just to ensure that
:> it stays in sync with the kernel.
:
: Isn't this in direct conflict with the instructions given for
:normally using vinum?
:Matt,
: help me understand your patch. this is how i read it at this
:time:
:
:
:Matt has just made available an early patch that corrects the vinum
:panic. is this the same vinum panic that people are claiming phk
:created with the bio/buf changes? i dont know the vinum code. i dont
:k
At 9:49 AM -0700 2000/4/5, Matthew Dillon wrote:
> Also, as a general note to everyone, make sure you are building vinum
> into the kernel directly and not using it as a kld, just to ensure that
> it stays in sync with the kernel.
Isn't this in direct conflict with the ins
>
> I've tracked down two bugs in vinum's raid5 implementation and
> submitted a tentitive patch to Greg for evaluation. It seems
> to fix the panics I was able to reproduce. The patch is available
> (but note that once Greg commits the real fix, you need to wipe it
> befor
:
:On Apr 05, Matthew Dillon wrote:
:> (needless to say, the patch I posted is relative to FreeBSD-4.x, not 5)
:>
:> -Matt
:> Matthew Dillon
:> <[EMAIL PROTECTED]>
:>
:
: He
On Apr 05, Matthew Dillon wrote:
> (needless to say, the patch I posted is relative to FreeBSD-4.x, not 5)
>
> -Matt
> Matthew Dillon
> <[EMAIL PROTECTED]>
>
Here's wha
(needless to say, the patch I posted is relative to FreeBSD-4.x, not 5)
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsu
I've tracked down two bugs in vinum's raid5 implementation and
submitted a tentitive patch to Greg for evaluation. It seems
to fix the panics I was able to reproduce. The patch is available
(but note that once Greg commits the real fix, you need to wipe it
before you cvs upd
Greg Lehey wrote:
> Technical explanation: A buffer header gets corrupted between the
> time the top half of the driver issues the request to the disk
> driver, and when the I/O completes. Currently, the evidence is
> pointing towards the disk driver, but the corruption is of such an
> u
In message <[EMAIL PROTECTED]>, Greg Lehey writes:
>>
>> The problem in vinum/releng4 is the problem greg has been blaming
>> on CAM since at least FreeBSDcon and indications seems to be that
>> it is actually a malloc/free gottcha in vinum.
>
>No, this is not correct. The problem you're talking
* Bernd Walter <[EMAIL PROTECTED]> [000326 01:51] wrote:
> On Sun, Mar 26, 2000 at 01:15:07AM -0800, Alfred Perlstein wrote:
> >
> > I recently (tonight) I cvsup'd to 5.0 to play with Matt's SMP stuff
> > and came across a problem where it seems that 5.0 doesn't get any
> > IO down to my vinum st
In message <[EMAIL PROTECTED]>, Alfred Perlstein writes:
>> >I'll get panics,
>>
>> You should know better than expect help providing only this little
>> information...
>
>Poul, is your mailer broken in such a way that you can't quote the
>entire message?
If you had at least told me what panic y
On Sun, Mar 26, 2000 at 11:49:05AM -0800, Alfred Perlstein wrote:
> Poul, is your mailer broken in such a way that you can't quote the
> entire message?
I doubt it. One should NOT quote entire messages, only the applicable
parts.
--
-- David([EMAIL PROTECTED])
To Unsubscribe: send mail t
1 - 100 of 148 matches
Mail list logo
