Vinum configuration lost at vinum stop / start
Kim Helenius
tristan at cc.jyu.fi
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
More information about the freebsd-questions
mailing list