Vinum configuration lost at vinum stop / start

Thu Nov 11 09:41:46 PST 2004

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 at 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 at cc.jyu.fi