Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 6 Jan 2001 10:17:50 +1030
From:      Greg Lehey <grog@lemis.com>
To:        Tor.Egge@fast.no
Cc:        blk@skynet.be, andy.depetter@ops.skynet.be, freebsd-stable@FreeBSD.ORG
Subject:   Re: Problems with corrupted vinum devices...
Message-ID:  <20010106101750.Z48589@wantadilla.lemis.com>
In-Reply-To: <200101051644.RAA17887@midten.fast.no>; from Tor.Egge@fast.no on Fri, Jan 05, 2001 at 05:44:02PM %2B0100
References:  <v0422080ab67b97176227@[172.17.1.121]> <200101051644.RAA17887@midten.fast.no>

next in thread | previous in thread | raw e-mail | index | archive | help
On Friday,  5 January 2001 at 17:44:02 +0100, Tor.Egge@fast.no wrote:
>> 	However, at some point within the next couple of hours (we're not
>> quite sure when), the machine crashed, and vinum failed to come up on
>> the reboot.  We had to comment out the /etc/fstab entries that
>> referred to the vinum volumes, and since then have been trying to
>> debug the problems as to why vinum can't find or start any devices at
>> all.
>
> I suggest increasing INITIAL_DRIVES in vinumvar.h to avoid array
> resize and the associated race conditions.  When I tried to configure
> vinum to use 14 disks yesterday, the machine immediately crashed with
> a trap 12 in response to 'vinum create'.  I bumped INITIAL_DRIVES to
> 16 to avoid the drive array resize that caused the problem.  I bumped
> INITIAL_SUBDISKS_IN_PLEX too, just to be safe.

I don't think these issues are related.  I'm still trying to figure
out what Brad did, but my best guess is some problem with the disk
labelling.

> To avoid similar races with RAID-5 under high load or with
> softupdates, I had to bump INITIAL_LOCKS to avoid a fatal range lock
> array resize.
>
> For 4.2-STABLE, I'm currently using the following patch to implement
> the workarounds:

Wait for me to test it and I'll commit it.  At this stage I don't
think there's any great advantage in distributing patches.

Greg
--
Finger grog@lemis.com for PGP public key
See complete headers for address and phone numbers


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010106101750.Z48589>