Vinum configuration lost at vinum stop / start
Stijn Hoop
stijn at win.tue.nl
Thu Nov 11 07:09:51 PST 2004
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
--
Apparently, 1 in 5 people in the world are Chinese. And there are 5 people
in my family, so it must be one of them. It's either my mum or my dad......
or maybe my older brother John. Or my younger brother Ho-Cha-Chu. But I'm
pretty sure it's John.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20041111/72c75e56/attachment.bin
More information about the freebsd-questions
mailing list