Re: freebsd 5.3 have any problem with vinum ?
Matthias Schuendehuette wrote: I'm not sure if this is a problem of (g)vinum or if FreeBSD has other problems in this area. just logged a kern bug on this And we all have to consider that gvinum is in a relatively early development phase (IMHO) - it is basically working, that is, it's possible to continue an existing 'classic' vinum installation with gvinum but it's still not fully functional in all depth. (minor deletes) I guess my issue is that there should be something in the release notes/updating that says "gvinum raid5 is not fully funtional at this time". I would argue that if can't survive a disk failure, it's not really RAID5. You might as well just go stripe and at least get the disk space back. If I hadn't sat down and tested this, I wouldn't have known it was broke till I had a drive failure which is not a good time to find out. I like (in general) where this is heading, but we seem to be inbetween relieable s/w raid5 solutions in FreeBSD. jim ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: freebsd 5.3 have any problem with vinum ?
Hello, Am Mittwoch, 10. November 2004 22:31 schrieben Sie: > ok, your instructions worked like a charm. So i'm running my nice 4 > member SCSI gvinum raid5 array (with softupdates turned on), and it's > zipping along. Fine! :-) > Now I need to test just how robust this is. Ouhh... ;-) > camcontrol is too nice. I want to test a more real world failure. > I'm running dbench and just pull one of the drives. My expectation > is that I should see a minor pause, and then the array continue in > some slower, degraded mode. That was mine too... > What I get is a kernel trap 12 (boom!). > I reboot, and it will not mount the degraded set till I replace the > drive. > > I turned off softupdates, and had the same thing happen. Is this a > bogus test? Is it reasonable to expect that a scsi drive failure > should of been tolerated w/o crashing? No, of course not. I have more or less the same problems here. Once I came so far as to delete the crashed subdisk but when I tried to delete the (not existing anymore) vinumdrive, my kernel also crashed... Well, to be honest, I once tried to pull the plug on one of my disks with 'classic' vinum and I got a kernel panic as well. OK, this happened a few years ago and I never tried that again... I'm not sure if this is a problem of (g)vinum or if FreeBSD has other problems in this area. And we all have to consider that gvinum is in a relatively early development phase (IMHO) - it is basically working, that is, it's possible to continue an existing 'classic' vinum installation with gvinum but it's still not fully functional in all depth. But I think, there's all the potential to get there. I have the impression that Lukas is *very* interested in his baby and I have a good overall feeling so far. But he's the only one developing gvinum AFAIK... And - my primary interest is the LVM functionality of (g)vinum. IMHO if you *really* have valuable data to protect, you can afford a hardware RAID-controller (*and* a tape drive :-). Anything else is wrong economy. But the current disk layout possibilities with up to four slices and at max 28 BSD-partitions are far to inflexible for todays large disks. So from this point of view I'm already fairly happy with gvinum as it is today. Which doesn't mean that I'm not trying to help to get gvinum to the place and state where it deserves to be... :-) -- Ciao/BSD - Matthias Matthias Schuendehuette , Berlin (Germany) PGP-Key at and ID: 0xDDFB0A5F ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: freebsd 5.3 have any problem with vinum ?
ok, your instructions worked like a charm. So i'm running my nice 4 member SCSI gvinum raid5 array (with softupdates turned on), and it's zipping along. Now I need to test just how robust this is. camcontrol is too nice. I want to test a more real world failure. I'm running dbench and just pull one of the drives. My expectation is that I should see a minor pause, and then the array continue in some slower, degraded mode. What I get is a kernel trap 12 (boom!). I reboot, and it will not mount the degraded set till I replace the drive. I turned off softupdates, and had the same thing happen. Is this a bogus test? Is it reasonable to expect that a scsi drive failure should of been tolerated w/o crashing? (bunch of scsi msgs to console) sub-disk down plex degraded g_access failed:6 trap 12 page fault while in kernel mode cpuid=1 apic id=01 fault virtual address =0x18c fault code supervisor write, page not present instruction pointer =0x8:0xc043d72c stack pointer =0x10:cbb17bf0 code segment=base 0x0, limit 0xfff, type 0x1b =DPL0, pres1,def32,gran1 Processor flagsinterupt enabled, resume,IOPL=0 current process22(irq11:ahc1) Matthias Schuendehuette wrote: gvinum> start This (as far as I investigated :-) a) initializes a newly created RAID5-plexor b) recalculates parity informations on a degraded RAID5-plex with a new replaced subdisk. So, a 'gvinum start raid5.p0' initializes my RAID5-plex if newly created. You can monitor the initialization process with subsequent 'gvinum list' commands. If you degrade a RAID5-plex with 'camcontrol stop ' (in case of SCSI-Disks) and 'repair' it afterwards with 'camcontrol start ', the 'gvinum start raid5.p0' (my volume here is called 'raid5') command recalculates the parity and revives the subdisk which was on disk . ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: freebsd 5.3 have any problem with vinum ?
It did, but can you tell me anywhere in the docs it says to do that? Or maybe that vinum should sense that and throw some error rather than just blindly corrupting itself. jim On Sun, 2004-11-07 at 09:38, Joe Koberg wrote: > secmgr wrote: > > > >No, I mean self corrupting raid5 sets during initialization. Discussed > >about 2-3 weeks ago. > > > > > In the following message you seemed to claim that adding 64 sectors of > slack to the > beginning of the vinum partition fixed this problem, as I suggested. Did > that fix it or not? > > > > The reason is empirically derived. When I created a 7 disk raid 5 set > > using "len 0" or all the space available, the raid set would be > > corrupt after initializing. Every time. When I reserved back that > > extra space, no corruption. > > (freebsd 4.10-p3) There was a thread on this a few days ago. > > > > jim > > > > Joe Koberg > joe at osoft dot us > > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: freebsd 5.3 have any problem with vinum ?
secmgr wrote: No, I mean self corrupting raid5 sets during initialization. Discussed about 2-3 weeks ago. In the following message you seemed to claim that adding 64 sectors of slack to the beginning of the vinum partition fixed this problem, as I suggested. Did that fix it or not? The reason is empirically derived. When I created a 7 disk raid 5 set using "len 0" or all the space available, the raid set would be corrupt after initializing. Every time. When I reserved back that extra space, no corruption. (freebsd 4.10-p3) There was a thread on this a few days ago. jim Joe Koberg joe at osoft dot us ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: freebsd 5.3 have any problem with vinum ?
Am Sonntag, 7. November 2004 06:30 schrieb secmgr: > On Sat, 2004-11-06 at 04:16, Matthias Schuendehuette wrote: > > Did you try to simply 'start' the plex? This works for > > initialisation of a newly created RAID5-Plex as well as for > > recalculating parity informations on a degraded RAID5-Plex. > > I did a gvinum start. No, that's not what I meant. 'gvinum start' loads the kernel module which in turn searches for vinum-GEOMs and loads the configuration data. It doesn't change the state of any gvinum item. Try 'gvinum start ' or within gvinum(8): gvinum> start This (as far as I investigated :-) a) initializes a newly created RAID5-plexor b) recalculates parity informations on a degraded RAID5-plex with a new replaced subdisk. So, a 'gvinum start raid5.p0' initializes my RAID5-plex if newly created. You can monitor the initialization process with subsequent 'gvinum list' commands. If you degrade a RAID5-plex with 'camcontrol stop ' (in case of SCSI-Disks) and 'repair' it afterwards with 'camcontrol start ', the 'gvinum start raid5.p0' (my volume here is called 'raid5') command recalculates the parity and revives the subdisk which was on disk . -- Ciao/BSD - Matthias Matthias Schuendehuette , Berlin (Germany) PGP-Key at and ID: 0xDDFB0A5F ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: freebsd 5.3 have any problem with vinum ?
I did a gvinum start. On Sat, 2004-11-06 at 04:16, Matthias Schuendehuette wrote: > Am Mittwoch, 3. November 2004 21:27 schrieb secmgr: > > Just ran into this myself. I had a perfectly happy raid 5 plex under > > 5.3 RC1. I upgrade to RC2, and the whole plex goes stale. I deleted > > everything from the volume on down (except for the drives), and tried > > to recreate the vol/plex/sd's. gvinum creates them, but they come > > back (like the undead) as stale and unusable (just like they were > > before). I'm finding commands documented (in help), but unimplemented > > (checkparity? init?). > > Did you try to simply 'start' the plex? This works for initialisation of > a newly created RAID5-Plex as well as for recalculating parity > informations on a degraded RAID5-Plex. > > It's that simple (at least for me on 5-STABLE) but admittedly > undocumented. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: freebsd 5.3 have any problem with vinum ?
No, I mean self corrupting raid5 sets during initialization. Discussed about 2-3 weeks ago. On Sat, 2004-11-06 at 05:09, Matthias Schuendehuette wrote: > > If you mean the 'dangling vnode'-problem with "vinum-classic": > > Try to start 'classic' vinum *after* the system has come up. Either > manually or perhaps with a script in /usr/local/etc/rc.d. This works > for me until now under 5-STABLE (a.k.a. RELENG_5). ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: freebsd 5.3 have any problem with vinum ?
On Monday, 1 November 2004 at 10:05:16 +1100, Carl Makin wrote: > Greg 'groggy' Lehey wrote: > >> On Monday, 25 October 2004 at 14:21:33 -0600, secmgr wrote: >> >> >> >> It's beginning to look like that's a bad idea. Lukas is >> (understandably) working only on gvinum, and since I know it's nearly >> there, I'm not going to do any further work on Vinum in FreeBSD 5. >> Given the problems, I'd suggest that we yank it. > > Do you want to yank it in 5 or 6-CURRENT? Well, it's been yanked in -CURRENT. My understanding was that it should also be yanked in 5.x: a number of changes have been made that effectively break old Vinum, > There are a *lot* of people using vinum and yanking it in 5-STABLE > would force us all to use the 5.3 security branch until gvinum > caught up. Yes, I'm afraid so. I can think of better ways that this could have been managed, but I haven't had much influence. Greg -- See complete headers for address and phone numbers. pgpaGayfYyURY.pgp Description: PGP signature
Re: freebsd 5.3 have any problem with vinum ?
Am Mittwoch, 3. November 2004 21:27 schrieb secmgr: > I hate to sound like a whiney baby, but WTF > is going on? It feels like vinum from 4.x has basicly been abandoned > (short of crashes with no workaround), and gvinum ain't near ready > for primetime. If you mean the 'dangling vnode'-problem with "vinum-classic": Try to start 'classic' vinum *after* the system has come up. Either manually or perhaps with a script in /usr/local/etc/rc.d. This works for me until now under 5-STABLE (a.k.a. RELENG_5). -- Ciao/BSD - Matthias Matthias Schuendehuette , Berlin (Germany) PGP-Key at and ID: 0xDDFB0A5F pgpme8ARVpsD3.pgp Description: PGP signature
Re: freebsd 5.3 have any problem with vinum ?
Am Mittwoch, 3. November 2004 21:27 schrieb secmgr: > Just ran into this myself. I had a perfectly happy raid 5 plex under > 5.3 RC1. I upgrade to RC2, and the whole plex goes stale. I deleted > everything from the volume on down (except for the drives), and tried > to recreate the vol/plex/sd's. gvinum creates them, but they come > back (like the undead) as stale and unusable (just like they were > before). I'm finding commands documented (in help), but unimplemented > (checkparity? init?). Did you try to simply 'start' the plex? This works for initialisation of a newly created RAID5-Plex as well as for recalculating parity informations on a degraded RAID5-Plex. It's that simple (at least for me on 5-STABLE) but admittedly undocumented. -- Ciao/BSD - Matthias Matthias Schuendehuette , Berlin (Germany) PGP-Key at and ID: 0xDDFB0A5F pgptKVpJvEOEJ.pgp Description: PGP signature
Re: freebsd 5.3 have any problem with vinum ?
Adrian Wontroba wrote: On Mon, Nov 01, 2004 at 10:05:16AM +1100, Carl Makin wrote: Do you want to yank it in 5 or 6-CURRENT? There are a *lot* of people using vinum and yanking it in 5-STABLE would force us all to use the 5.3 security branch until gvinum caught up. From my experiences today with setting up a very old machine[1] with 5.3-RC2, I think it would be best to keep both until gvinum had caught up. Vinum can do things which gvinum appears incapable of - such as initialising a RAID-5 plex. Just ran into this myself. I had a perfectly happy raid 5 plex under 5.3 RC1. I upgrade to RC2, and the whole plex goes stale. I deleted everything from the volume on down (except for the drives), and tried to recreate the vol/plex/sd's. gvinum creates them, but they come back (like the undead) as stale and unusable (just like they were before). I'm finding commands documented (in help), but unimplemented (checkparity? init?). I hate to sound like a whiney baby, but WTF is going on? It feels like vinum from 4.x has basicly been abandoned (short of crashes with no workaround), and gvinum ain't near ready for primetime. We need a stable, working s/w raid solution (or admit that as of right now, FreeBSD doesn't have one). At the very least, we need re and the authors to document what works, what doesn't, and what never will. I'd happily help with docs, but right now it seems like product function is linked to /dev/random. If gvinum isn't ready for release (my personal opinion after RC2), it needs to be pulled until whats documented works, and what works, is documented correctly. jim ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: freebsd 5.3 have any problem with vinum ?
On Mon, Nov 01, 2004 at 10:05:16AM +1100, Carl Makin wrote: > Do you want to yank it in 5 or 6-CURRENT? There are a *lot* of people > using vinum and yanking it in 5-STABLE would force us all to use the 5.3 > security branch until gvinum caught up. >From my experiences today with setting up a very old machine[1] with 5.3-RC2, I think it would be best to keep both until gvinum had caught up. Vinum can do things which gvinum appears incapable of - such as initialising a RAID-5 plex. -- Adrian Wontroba [1] A Fujitsu M700 4 way Ppro - the state of the art in 1997 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: freebsd 5.3 have any problem with vinum ?
Hi Greg, Greg 'groggy' Lehey wrote: On Monday, 25 October 2004 at 14:21:33 -0600, secmgr wrote: It's beginning to look like that's a bad idea. Lukas is (understandably) working only on gvinum, and since I know it's nearly there, I'm not going to do any further work on Vinum in FreeBSD 5. Given the problems, I'd suggest that we yank it. Do you want to yank it in 5 or 6-CURRENT? There are a *lot* of people using vinum and yanking it in 5-STABLE would force us all to use the 5.3 security branch until gvinum caught up. Carl. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: freebsd 5.3 have any problem with vinum ?
On Friday, 29 October 2004 at 14:20:40 -0600, secmgr wrote: > Greg 'groggy' Lehey wrote: > >> A bit of background: we know that 'gvinum' will replace Vinum; the >> original intention had been to do it seamlessly, but for various >> reasons that did happen. Then we decided that we should leave them >> both in the tree until gvinum had the full functionality of Vinum. >> It's beginning to look like that's a bad idea. Lukas is >> (understandably) working only on gvinum, and since I know it's nearly >> there, I'm not going to do any further work on Vinum in FreeBSD 5. >> Given the problems, I'd suggest that we yank it. I'm copying the >> release engineering team. Re, what do you think? > > Not that I've got a lot of say in the matter, but I would vote for this > too. (along with migration info in the release notes). I've spoken to Scott Long on the subject, and it looks likely that we'll do something like this; but re haven't made a final decision. > There are also some minor changes needed to the docs on vinumvm.org > for gvinum/newfs (5.3) to correct new paths and switches. So far, vinumvm.org has no information about gvinum at all. Hopefully that will change at some time. Greg -- See complete headers for address and phone numbers ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: freebsd 5.3 have any problem with vinum ?
Greg 'groggy' Lehey wrote: A bit of background: we know that 'gvinum' will replace Vinum; the original intention had been to do it seamlessly, but for various reasons that did happen. Then we decided that we should leave them both in the tree until gvinum had the full functionality of Vinum. It's beginning to look like that's a bad idea. Lukas is (understandably) working only on gvinum, and since I know it's nearly there, I'm not going to do any further work on Vinum in FreeBSD 5. Given the problems, I'd suggest that we yank it. I'm copying the release engineering team. Re, what do you think? Greg Not that I've got a lot of say in the matter, but I would vote for this too. (along with migration info in the release notes). There are also some minor changes needed to the docs on vinumvm.org for gvinum/newfs (5.3) to correct new paths and switches. thanks jim ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: freebsd 5.3 have any problem with vinum ?
On Monday, 25 October 2004 at 14:21:33 -0600, secmgr wrote: > Andrew Konstantinov wrote: > >> On Mon, 2004-10-25 at 05:55, Oliver Torres Delgado wrote: >> >> >>> I have freebsd 5.3 rc1 installed perfectly, i configure vinum with the >>> handbook and all work perfect >>> but when try run vinum with rc.conf there display the error: >>> >>> panic: unmount: dangling vnode >>> ... >> >> Just like me, you should have checked the mailing list archive first. >> Here is a nice solution: >> http://lists.freebsd.org/pipermail/freebsd-current/2004-August/035547.html > > thanks, I appreciate the pointer. That being said, if this is a "KNOWN" > problem (as far back as August) how come no mention in either the > release notes OR errata. Good question. > I like and use FreeBSD for it's stability, but at this point in > time, I've got broken vinum-classic (with workarounds) raid5 in 4.10 > and raid 1 in 5.3-stable. Both of these installed per current > documentation. I haven't logged bug reports becasue it seems like > everything is moving to gvinum, and they'd probably just end up > closed out as FINV A bit of background: we know that 'gvinum' will replace Vinum; the original intention had been to do it seamlessly, but for various reasons that did happen. Then we decided that we should leave them both in the tree until gvinum had the full functionality of Vinum. It's beginning to look like that's a bad idea. Lukas is (understandably) working only on gvinum, and since I know it's nearly there, I'm not going to do any further work on Vinum in FreeBSD 5. Given the problems, I'd suggest that we yank it. I'm copying the release engineering team. Re, what do you think? Greg -- See complete headers for address and phone numbers ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: freebsd 5.3 have any problem with vinum ?
Andrew Konstantinov wrote: On Mon, 2004-10-25 at 05:55, Oliver Torres Delgado wrote: I have freebsd 5.3 rc1 installed perfectly, i configure vinum with the handbook and all work perfect but when try run vinum with rc.conf there display the error: panic: unmount: dangling vnode cpuid: 0 uptime= 4s Cannot dump. No dump device defined Automatic reboot in 15 seconds. Just like me, you should have checked the mailing list archive first. Here is a nice solution: http://lists.freebsd.org/pipermail/freebsd-current/2004-August/035547.html I switched from 5.2.1 to 5.3 and had the same problem which you'ved described above. Once I've switched to gvinum, everything went back to normal. Andrew thanks, I appreciate the pointer. That being said, if this is a "KNOWN" problem (as far back as August) how come no mention in either the release notes OR errata. I like and use FreeBSD for it's stability, but at this point in time, I've got broken vinum-classic (with workarounds) raid5 in 4.10 and raid 1 in 5.3-stable. Both of these installed per current documentation. I haven't logged bug reports becasue it seems like everything is moving to gvinum, and they'd probably just end up closed out as FINV jim ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: freebsd 5.3 have any problem with vinum ?
On Mon, 2004-10-25 at 05:55, Oliver Torres Delgado wrote: > I have freebsd 5.3 rc1 installed perfectly, i configure vinum with the handbook and > all work perfect > but when try run vinum with rc.conf there display the error: > > panic: unmount: dangling vnode > cpuid: 0 > uptime= 4s > Cannot dump. No dump device defined > Automatic reboot in 15 seconds. > > why happened ? I configure freebsd 4.x with this config and work perfectly :( Just like me, you should have checked the mailing list archive first. Here is a nice solution: http://lists.freebsd.org/pipermail/freebsd-current/2004-August/035547.html I switched from 5.2.1 to 5.3 and had the same problem which you'ved described above. Once I've switched to gvinum, everything went back to normal. Andrew ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[Fwd: Re: freebsd 5.3 have any problem with vinum ?]
I have freebsd 5.3 rc1 installed perfectly, i configure vinum with the handbook and all work perfect but when try run vinum with rc.conf there display the error: panic: unmount: dangling vnode cpuid: 0 uptime= 4s Cannot dump. No dump device defined Automatic reboot in 15 seconds. why happened ? I configure freebsd 4.x with this config and work perfectly :( thx to alls. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" just hit the same exact thing myself. two single drive plexes, mirored. If I boot standalone, bring up vinum by hand, and then mount the mirror, it's fine. Only happens when I use the start_vinum="YES" in rc.conf. jim ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
freebsd 5.3 have any problem with vinum ?
I have freebsd 5.3 rc1 installed perfectly, i configure vinum with the handbook and all work perfect but when try run vinum with rc.conf there display the error: panic: unmount: dangling vnode cpuid: 0 uptime= 4s Cannot dump. No dump device defined Automatic reboot in 15 seconds. why happened ? I configure freebsd 4.x with this config and work perfectly :( thx to alls. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
