From owner-freebsd-fs Mon Apr 2 21:39:36 2001 Delivered-To: freebsd-fs@freebsd.org Received: from peter3.wemm.org (c1315225-a.plstn1.sfba.home.com [65.0.135.147]) by hub.freebsd.org (Postfix) with ESMTP id 2CF1F37B722 for ; Mon, 2 Apr 2001 21:39:30 -0700 (PDT) (envelope-from peter@netplex.com.au) Received: from mobile.wemm.org (mobile.wemm.org [10.0.0.5]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id f334dRM59224 for ; Mon, 2 Apr 2001 21:39:27 -0700 (PDT) (envelope-from peter@netplex.com.au) Received: from netplex.com.au (localhost [127.0.0.1]) by mobile.wemm.org (8.11.1/8.11.1) with ESMTP id f334dLh17759; Mon, 2 Apr 2001 21:39:21 -0700 (PDT) (envelope-from peter@netplex.com.au) Message-Id: <200104030439.f334dLh17759@mobile.wemm.org> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Greg Lehey Cc: Kirk Strauser , freebsd-fs@FreeBSD.ORG Subject: Re: My Vinum heart attack In-Reply-To: <20010403093947.K25226@wantadilla.lemis.com> Date: Mon, 02 Apr 2001 21:39:21 -0700 From: Peter Wemm Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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. 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. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message