Date: Mon, 02 Apr 2001 22:20:08 -0700 From: Peter Wemm <peter@netplex.com.au> To: Greg Lehey <grog@lemis.com> Cc: Kirk Strauser <kirk@strauser.com>, freebsd-fs@FreeBSD.ORG Subject: Re: My Vinum heart attack Message-ID: <200104030520.f335K8h18102@mobile.wemm.org> In-Reply-To: <20010403141308.N71213@wantadilla.lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Greg Lehey wrote:
> 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 <des@ofug.org> writes:
> >>>
> >>>> There is no critical information in /dev/vinum. The information there ca
n
> >>>> easily be recreated by vinum(8) from the configuration information store
d
> >>>> 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 attentio
n
> >>> 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 b
e
>>> 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.
Using the module, there are three things you have to juggle to keep in sync..
kernel, module (vinum.ko), /sbin/vinum. Compiling vinum into the kernel
means you only have to deal with two of them. Getting kernel/userland out
of sync is usually a lot less destructive than getting kernel/module out of
sync (witness this problem report).
> But you're free to fix it.
Cool.. I can remove the instructions saying to use the module and change
them to say to compile it into the kernel? :-)
> > 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.
Which it has done on a regular basis over the last few months.
Not to mention the whole "dev_t" thing that is embedded in these interface
structures.. (on freebsd, dev_t is a pointer in kernel context and an
integer in user context. On an alpha, these are a different size which
tends to mess up your day)
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200104030520.f335K8h18102>