From owner-freebsd-fs Mon Apr 2 21:43:42 2001 Delivered-To: freebsd-fs@freebsd.org Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.80]) by hub.freebsd.org (Postfix) with ESMTP id B696737B71B for ; Mon, 2 Apr 2001 21:43:27 -0700 (PDT) (envelope-from grog@lemis.com) Received: by wantadilla.lemis.com (Postfix, from userid 1004) id 22F336ACBA; Tue, 3 Apr 2001 14:13:08 +0930 (CST) Date: Tue, 3 Apr 2001 14:13:08 +0930 From: Greg Lehey To: Peter Wemm Cc: Kirk Strauser , freebsd-fs@FreeBSD.ORG Subject: Re: My Vinum heart attack Message-ID: <20010403141308.N71213@wantadilla.lemis.com> References: <20010403093947.K25226@wantadilla.lemis.com> <200104030439.f334dLh17759@mobile.wemm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200104030439.f334dLh17759@mobile.wemm.org>; from peter@netplex.com.au on Mon, Apr 02, 2001 at 09:39:21PM -0700 Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Monday, 2 April 2001 at 21:39:21 -0700, Peter Wemm wrote: > Greg Lehey wrote: >> On Monday, 2 April 2001 at 8:28:38 -0500, Kirk Strauser wrote: >>> >>> At 2001-04-02T13:12:37Z, Dag-Erling Smorgrav writes: >>> >>>> There is no critical information in /dev/vinum. The information there can >>>> easily be recreated by vinum(8) from the configuration information stored >>>> on the disks themselves. >>> >>> I wasn't too sure at the time which information was canonical - the copy in >>> /dev/vinum, or the on-disk copy - so I wanted to be darn sure not to lose >>> more than I needed to. >>> >>> Your point that it is easily recreated is true, given that vinum works at >>> all in a particular situation. Mine didn't. I know why it didn't, and I >>> managed to work through it without loss, but it certainly got my attention >>> at the time. >>> >>> BTW, my note was much more a warning to others to pay attention to these >>> things than a complaint. Vinum is a complicated thing, and you have to be >>> willing to rise to the occasion if you want to use it, and I'm comfortable >>> with that. >> >> The real issue here is that you seemed to think it OK to update your >> kernel and not update userland. Experienced people will say "that's a >> no-no", but somehow you were able to get that impression. I'm still >> planning to investigate how this could happen. > > This is made far far worse by pushing part of the kernel out into the > userland (ie: vinum.ko). This is why I still tell people regularly that > that get burned bu this that they should be using 'device vinum' and > 'options VINUM_DEBUG' to match the userland defaults. I usually get into > the habit of keeping several aged instances of /sbin/vinum.* because the > vinum kernel<->userland ABI is so extremely fragile. You should be keeping matched kld/kernel pairs. But you're free to fix it. > In -current the dynamics are a little different. By default, the > vinum module is installed with a 'make install' of the kernel, so > you usually get the same results as when you have it compiled into > the kernel. However, the user-kernel interface is far more broken > because it has things like 'struct mtx' embedded inside the ioctl > interfaces.. :-( This changes often, and vinum breaks each and every > time. Only if you get out of sync, and if the *size* of struct mtx changes. 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-fs" in the body of the message