Date: Thu, 19 Sep 2002 14:44:20 +0930 From: Greg 'groggy' Lehey <grog@FreeBSD.org> To: Jaime Bozza <jbozza@thinkburst.com> Cc: freebsd-stable@FreeBSD.ORG Subject: Re: vinum ad0h/ad0s1h issue Message-ID: <20020919051420.GH37454@wantadilla.lemis.com> In-Reply-To: <025001c25f43$a57fd120$6401010a@bozza> References: <15612.59696.734708.21623@horsey.gshapiro.net> <025001c25f43$a57fd120$6401010a@bozza>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday, 18 September 2002 at 13:46:06 -0500, Jaime Bozza wrote:
> Recently I wrote a message regarding some filesystem problems. One of
> the differences I noticed on the system was that my drives were
> referencing ad0/2h instead of ad0/2s1h. I also stated that rebooting
> solved the problem.
>
> I was just able to duplicate the problem. Here's what I found out.
>
> (Happens on a recent 4.7-RC, vinum configuration with start_vinum="YES")
>
> First, boot into single-user mode.
>
> Next, mount / (for rw), then run 'vinum start'. Vinum reads the data
> from ad0s1h/ad2s1h correctly.
>
> (I had then run my fsck's and such on the drives when I had the problem)
>
> Exit the single-user shell (which starts booting into multiuser)
>
> /etc/rc and friends run 'vinum start' a second time, which causes the
> system to read data from ad0h/ad2h. System seems to be fine except for
> "vinum ld". When rebooting the system and letting it come up normally,
> it reads the slices correctly.
>
> If I run "vinum stop" before exiting single-user mode, it works fine.
> In fact, I can easily duplicate the error just by running "vinum start"
> twice. (BTW, a third time will panic the system and cause vinum to read
> the ad0h/ad2h on reboot)
Hmm. This is beginning to make a little more sense.
> You said it was a known problem. How difficult would it be to
> ingore subsequent start's (The overall start kind) once vinum has
> already been "started", or could there be a situation where you'd
> want to start it more than once?
Yes.
> (I can't think of any)
You hot plug some drives into the system and want to start them.
I think I now understand the problem here. Try the following patch
and tell me if it solves the problem:
--- vinumio.c 2 May 2002 08:43:44 -0000 1.52.2.6
+++ vinumio.c 19 Sep 2002 05:10:27 -0000
@@ -883,29 +883,6 @@
}
}
}
- if (founddrive == 0) { /* didn't find anything, */
- for (part = 'a'; part < 'i'; part++) /* try the compatibility partition */
- if (part != 'c') { /* don't do the c partition */
- snprintf(partname, /* /dev/sd0a */
- DRIVENAMELEN,
- "%s%c",
- devicename[driveno],
- part);
- drive = check_drive(partname); /* try to open it */
- if ((drive->lasterror != 0) /* didn't work, */
- ||(drive->state != drive_up))
- free_drive(drive); /* get rid of it */
- else if (drive->flags & VF_CONFIGURED) /* already read this config, */
- log(LOG_WARNING,
- "vinum: already read config from %s\n", /* say so */
- drive->label.name);
- else {
- drivelist[gooddrives] = drive->driveno; /* keep the drive index */
- drive->flags &= ~VF_NEWBORN; /* which is no longer newly born */
- gooddrives++;
- }
- }
- }
}
if (gooddrives == 0) {
The problem here is that vinum_scandisk() tries to read from each
slice. If it doesn't find any (for example, on a dedicated disk), it
tries the compatibility slice. That normally works fine, but if all
of the slices have already been read, it still falls through into this
part. Removing it should solve your problem; the real solution is a
little more complicated and involves recognizing that we already know
this drive. I probably won't do that until I finally have the root
file system running on Vinum, which will require mods in this same
area.
Greg
--
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?20020919051420.GH37454>