Date: Thu, 11 Nov 2004 19:41:39 +0200 From: Kim Helenius <tristan@cc.jyu.fi> To: Stijn Hoop <stijn@win.tue.nl> Cc: freebsd-questions@freebsd.org Subject: Re: Vinum configuration lost at vinum stop / start Message-ID: <4193A453.90106@cc.jyu.fi> In-Reply-To: <20041111150948.GE635@pcwin002.win.tue.nl> References: <20041111121746.GY912@pcwin002.win.tue.nl> <Pine.LNX.4.44.0411111527470.17075-100000@silmu.st.jyu.fi> <20041111133935.GC635@pcwin002.win.tue.nl> <41937CF3.70502@cc.jyu.fi> <20041111150948.GE635@pcwin002.win.tue.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
Stijn Hoop wrote: > Hi, > > On Thu, Nov 11, 2004 at 04:53:39PM +0200, Kim Helenius wrote: > >>Stijn Hoop wrote: >> >>>I don't know the state of affairs for 5.2.1-RELEASE, but in 5.3-RELEASE >>>gvinum is the way forward. >> >>Thanks again for answering. Agreed, but there still seems to be a long >>way to go. A lot of 'classic' vinum functionality is still missing and >>at least for me it still doesn't do the job the way I would find >>trustworthy. See below. > > > That's absolutely true. While 5.3 is IMHO pretty stable, gvinum is quite new > and therefore a bit less well tested than the rest of the system. Fortunately > Lukas Ertl, the maintainer of gvinum, is pretty active and responsive to > problems. > > So if you need a critically stable vinum environment you would be better off > with 4.x. > > >>I tested gvinum with some interesting results. First the whole system >>froze after creating a concatenated drive and trying to gvinum -rf -r >>objects (resetconfig command doesn't exist). > > > That's not good. Nothing in dmesg? If you can consistently get this to happen > you should send in a problem report. > > >>Next, I created the volume, >>newfs, copied some data on it. The rebooted, and issued gvinum start. >> >>This is what follows: >> >>2 drives: >>D d1 State: up /dev/ad4s1d A: 285894/286181 >>MB (99%) >>D d2 State: up /dev/ad5s1d A: 285894/286181 >>MB (99%) >> >>1 volume: >>V vinum0 State: down Plexes: 1 Size: 572 MB >> >>1 plex: >>P vinum0.p0 C State: down Subdisks: 2 Size: 572 MB >> >>2 subdisks: >>S vinum0.p0.s0 State: stale D: d1 Size: 286 MB >>S vinum0.p0.s1 State: stale D: d2 Size: 286 MB >> >>I'm getting a bit confused. Issuing separately 'gvinum start vinum0' >>does seem to fix it (all states go 'up') but surely it should come up >>fine with just 'gvinum start'? This is how I would start it in loader.conf. > > > I think I've seen this too, but while testing an other unrelated problem. At > the time I attributed it to other factors. Can you confirm that when you > restart again, it stays up? Or maybe try an explicit 'saveconfig' when it is > in the 'up' state, and then reboot. > > >>>Have you read >>> >>>http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/current-stable.html >>> >>>Particularly the 19.2.2 section, 'Staying stable with FreeBSD'? >>> >> >>I have read it and used -stable in 4.x, and if I read it really >>carefully I figure out that -stable does not equal "stable" which is way >>I stopped tracking -stable in the first place. And when knowing I would >>only need it to fix raid5 init I'm a bit reluctant to do it as I found >>out I can't even create a concat volume correctly. > > > That I can understand. If I may make a polite suggestion, it sounds like you > value stability above all else. In this case where vinum is involved, I would > recommend you to stay with 4.x until 5.4 is released. That should take another > 6-8 months and probably most of the gvinum issues will have been tackled by > then. Although I know that there are a lot of users, myself included, that run > gvinum on 5.x, it is pretty new technology and therefore unfortunately > includes pretty new bugs. > > The other option is to bite the bullet now, and fiddle with gvinum for a few > days. Since other users are using it, it is certainly possible. This will > take you some time however. It will save you time when the upgrade to 5.4 will > be though. > > It is your decision what part of the tradeoff you like the most. > > HTH, > > --Stijn > Stability is exactly what I'm looking for. However, I begin to doubt there's something strange going on with my setup. I mentioned gvinum freezing - there's indeed a fatal kernel trap message (page fault) on the console. Now, then, thinking of good old FreeBSD 4.x I decided to spend some more time on this issue. Ok... so I tested vinum with FreeBSD 4.10 and amazing things just keep happening. Like with 5.x, I create a small test concat volume with vinum. Newfs, mount, etc, everything works. Now, then, I issue the following commands: vinum stop, then vinum start. Fatal kernel trap -> automatic reboot. So, the root of the problem must lie deeper than (g)vinum in 5.x. More info on my 5.3 setup: Copyright (c) 1992-2004 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.3-RELEASE #1: Mon Nov 8 21:43:07 EET 2004 tristan@e26b.mylly.jyu.fi:/usr/obj/usr/src/sys/KIUKKU Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(TM) XP 1600+ (1400.06-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x662 Stepping = 2 Features=0x383f9ff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE> AMD Features=0xc0480000<MP,AMIE,DSP,3DNow!> real memory = 536788992 (511 MB) avail memory = 519794688 (495 MB) npx0: [FAST] npx0: <math processor> on motherboard npx0: INT 16 interface acpi0: <ASUS A7M266> on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0xe408-0xe40b on acpi0 cpu0: <ACPI CPU (3 Cx states)> on acpi0 acpi_button0: <Power Button> on acpi0 pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0 pci0: <ACPI PCI bus> on pcib0 agp0: <AMD 761 host to AGP bridge> port 0xe000-0xe003 mem 0xf7800000-0xf7800fff,0xf8000000-0xfbffffff at device 0.0 on pci0 pcib1: <ACPI PCI-PCI bridge> at device 1.0 on pci0 pci1: <ACPI PCI bus> on pcib1 pci1: <display, VGA> at device 5.0 (no driver attached) isab0: <PCI-ISA bridge> at device 4.0 on pci0 isa0: <ISA bus> on isab0 atapci0: <VIA 82C686B UDMA100 controller> port 0xb800-0xb80f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 4.1 on pci0 ata0: channel #0 on atapci0 ata1: channel #1 on atapci0 pci0: <serial bus, USB> at device 4.3 (no driver attached) pci0: <old, non-VGA display device> at device 4.4 (no driver attached) xl0: <3Com 3c905C-TX Fast Etherlink XL> port 0x9400-0x947f mem 0xf4800000-0xf480007f irq 12 at device 9.0 on pci0 miibus0: <MII bus> on xl0 xlphy0: <3c905C 10/100 internal PHY> on miibus0 xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xl0: Ethernet address: 00:04:76:8d:fd:30 atapci1: < controller> port 0x7800-0x780f,0x8000-0x8003,0x8400-0x8407,0x8800-0x8803,0x9000-0x9007 mem 0xf4000000-0xf40000ff irq 10 at device 11.0 on pci0 ata2: channel #0 on atapci1 ata3: channel #1 on atapci1 xl1: <3Com 3c905C-TX Fast Etherlink XL> port 0x7400-0x747f mem 0xf3800000-0xf380007f irq 12 at device 13.0 on pci0 miibus1: <MII bus> on xl1 xlphy1: <3c905C 10/100 internal PHY> on miibus1 xlphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xl1: Ethernet address: 00:04:76:15:fd:e5 fdc0: <floppy drive controller> port 0x3f7,0x3f2-0x3f5 irq 6 drq 2 on acpi0 fdc0: [FAST] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 atkbdc0: <Keyboard controller (i8042)> port 0x64,0x60 irq 1 on acpi0 atkbd0: <AT Keyboard> irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] orm0: <ISA Option ROMs> at iomem 0xd4000-0xd47ff,0xc8000-0xc87ff,0xc0000-0xc7fff on isa0 pmtimer0 on isa0 sc0: <System console> at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounter "TSC" frequency 1400056823 Hz quality 800 Timecounters tick every 10.000 msec ipfw2 initialized, divert enabled, rule-based forwarding disabled, default to deny, logging limited to 200 packets/entry by default acpi_cpu: throttling enabled, 16 steps (100% to 6.2%), currently 100.0% ad0: 117246MB <Maxtor 6Y120L0/YAR41BW0> [238216/16/63] at ata0-master UDMA100 acd0: CDROM <TOSHIBA CD-ROM XM-6602B/1017> at ata1-master UDMA33 ad4: 286188MB <Maxtor 6B300R0/BAH419Z0> [581463/16/63] at ata2-master UDMA133 ad5: 286188MB <Maxtor 6B300R0/BAH419Z0> [581463/16/63] at ata2-slave UDMA133 ad6: 286188MB <Maxtor 6B300R0/BAH419Z0> [581463/16/63] at ata3-master UDMA133 ad7: 286188MB <Maxtor 6B300R0/BAH419Z0> [581463/16/63] at ata3-slave UDMA133 Relevant (I think) info: a pci ide controller based on "SiI 0680 UDMA133" chip (mentioned as supported in hardware notes of both 5.3 and 4.10) and 4x300GB "Maxtor DIAMONDMAX 10/300GB UATA133 7200RPM 16MB" disks. If you want more information on the kernel trap message I can scribble it down later. -- Kim Helenius tristan@cc.jyu.fi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4193A453.90106>