Re: [ GEOM tests ] disklabel warnings and vinum drives lost
In message [EMAIL PROTECTED], Poul-Henning Kamp writes:
Make that _three_ bugs: vinum opens devices directly at the cdevsw
level, bypassing in the process the vnodes and specfs.
Here is a patch that makes it use vn_open/vn_close/VOP_IOCTL,
bringing it much closer to the way ccd(4) does things. I have only
lightly tested this so far - I saw one problem where a md(4)
vnode-backed device got stuck in mddestroy(), but I haven't tracked
down if that is related (the md vnode was just a file on a vinum-backed
filesystem).
Ian
Index: vinumio.c
===
RCS file: /dump/FreeBSD-CVS/src/sys/dev/vinum/vinumio.c,v
retrieving revision 1.76
diff -u -r1.76 vinumio.c
--- vinumio.c 5 Oct 2002 03:44:00 - 1.76
+++ vinumio.c 5 Oct 2002 14:12:56 -
@@ -51,33 +51,26 @@
open_drive(struct drive *drive, struct thread *td, int verbose)
{
struct nameidata nd;
-struct cdevsw *dsw;/* pointer to
cdevsw entry */
-int error;
+int flags;
if (drive-flags VF_OPEN)/* open already, */
return EBUSY; /* don't do it again */
-NDINIT(nd, LOOKUP, FOLLOW | LOCKLEAF, UIO_SYSSPACE, drive-devicename,
-curthread);
-error = namei(nd);
-if (error)
- return (error);
-if (!vn_isdisk(nd.ni_vp, error)) {
- NDFREE(nd, 0);
- return (error);
-}
-drive-dev = udev2dev(nd.ni_vp-v_rdev-si_udev, 0);
-NDFREE(nd, 0);
-
-if (drive-dev == NULL)/* didn't find anything */
- return ENODEV;
-
-drive-dev-si_iosize_max = DFLTPHYS;
-dsw = devsw(drive-dev);
-if (dsw == NULL)
- drive-lasterror = ENOENT;
-else
- drive-lasterror = (dsw-d_open) (drive-dev, FWRITE | FREAD, 0, NULL);
+drive-devvp = NULL;
+NDINIT(nd, LOOKUP, FOLLOW, UIO_SYSSPACE, drive-devicename, td);
+flags = FREAD | FWRITE;
+drive-lasterror = vn_open(nd, flags, 0);
+if (drive-lasterror == 0) {
+ (void) vn_isdisk(nd.ni_vp, drive-lasterror);
+ if (drive-lasterror != 0 vrefcnt(nd.ni_vp) 1)
+ drive-lasterror = EBUSY;
+ VOP_UNLOCK(nd.ni_vp, 0, td);
+ NDFREE(nd, NDF_ONLY_PNBUF);
+ if (drive-lasterror == 0)
+ drive-devvp = nd.ni_vp;
+ else
+ (void) vn_close(nd.ni_vp, flags, td-td_ucred, td);
+}
if (drive-lasterror != 0) { /* failed */
drive-state = drive_down; /* just force it down */
@@ -85,8 +78,11 @@
log(LOG_WARNING,
vinum open_drive %s: failed with error %d\n,
drive-devicename, drive-lasterror);
-} else
+} else {
+ drive-dev = vn_todev(drive-devvp);
+ drive-dev-si_iosize_max = DFLTPHYS;
drive-flags |= VF_OPEN;/* we're open now */
+}
return drive-lasterror;
}
@@ -145,6 +141,9 @@
int
init_drive(struct drive *drive, int verbose)
{
+struct thread *td;
+
+td = curthread;
if (drive-devicename[0] != '/') {
drive-lasterror = EINVAL;
log(LOG_ERR, vinum: Can't open drive without drive name\n);
@@ -154,17 +153,17 @@
if (drive-lasterror)
return drive-lasterror;
-drive-lasterror = (*devsw(drive-dev)-d_ioctl) (drive-dev,
+drive-lasterror = VOP_IOCTL(drive-devvp,
DIOCGSECTORSIZE,
(caddr_t) drive-sectorsize,
FREAD,
- curthread);
+ td-td_ucred, td);
if (drive-lasterror == 0)
- drive-lasterror = (*devsw(drive-dev)-d_ioctl) (drive-dev,
+ drive-lasterror = VOP_IOCTL(drive-devvp,
DIOCGMEDIASIZE,
(caddr_t) drive-mediasize,
FREAD,
- curthread);
+ td-td_ucred, td);
if (drive-lasterror) {
if (verbose)
log(LOG_WARNING,
@@ -211,14 +210,16 @@
void
close_locked_drive(struct drive *drive)
{
+struct thread *td;
int error;
+td = curthread;
/*
* If we can't access the drive, we can't flush
* the queues, which spec_close() will try to
* do. Get rid of them here first.
*/
-error = (*devsw(drive-dev)-d_close) (drive-dev, 0, 0, NULL);
+error = vn_close(drive-devvp, FREAD | FWRITE, td-td_ucred, td);
drive-flags = ~VF_OPEN; /* no longer open */
if (drive-lasterror == 0)
drive-lasterror = error;
@@ -561,11 +562,13 @@
int error;
int written_config;/* set when we
first write the config to disk */
int driveno;
+struct thread *td;
struct drive *drive; /* point to current drive
info */
struct vinum_hdr *vhdr;/* and as header */
char *config; /*
Re: [ GEOM tests ] disklabel warnings and vinum drives lost
In message [EMAIL PROTECTED], n0go013 writes: rebuilt kernel with GEOM and everything is ok but disklabel now dumps a warning message for each undefined partition. should these be manually initialised to valid entries or is this a bug ? more importantly vinum can no longer find the drives but i'm not sure thats related as cvsup was from 2002/09/23 - 2002/10/03 I have just a couple of hours ago added the sysctl kern.disks to the GEOM code. I suspect vinum uses this sysctl to get an inventory of disks in the system, so can I get you to try again making sure you have rev. 1.20 of src/sys/geom/geom_disk.c ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [ GEOM tests ] disklabel warnings and vinum drives lost
On 04.10-14:20, Poul-Henning Kamp wrote: I suspect vinum uses this sysctl to get an inventory of disks in the system, so can I get you to try again making sure you have rev. 1.20 of src/sys/geom/geom_disk.c ? still in the middle of the build but i don't think so -- it looks like vinum is using BIO_READ with a fixed offset VINUM_LABEL_OFFSET to retrieve a raw copy of the disklabel to parse. i don't have any references but from what you've mentioned in commits over the last week that's not really going to work. if there are any geom design outlines i can read (in a digest or news) then i may be able to put together a patch. i'll let you know the test results when i have some. -- t t z To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [ GEOM tests ] disklabel warnings and vinum drives lost
On 04.10-15:40, fergus wrote: On 04.10-14:20, Poul-Henning Kamp wrote: [...] I suspect vinum uses this sysctl to get an inventory of disks in the system, so can I get you to try again making sure you have rev. 1.20 of src/sys/geom/geom_disk.c ? [...] i'll let you know the test results when i have some. same results -- can't initialise any drives. i think the example below points more directly to the issue but i'm pretty sure it is because the direct read from the disk does not return a valid disklabel. without a 'vinum' partition entry vinum spews. +++ vinum start +++ eyore# vinum start ** no drives found: No such file or directory --- vinum start --- -- t t z To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [ GEOM tests ] disklabel warnings and vinum drives lost
In message [EMAIL PROTECTED], n0go013 writes : On 04.10-15:40, fergus wrote: On 04.10-14:20, Poul-Henning Kamp wrote: [...] I suspect vinum uses this sysctl to get an inventory of disks in the system, so can I get you to try again making sure you have rev. 1.20 of src/sys/geom/geom_disk.c ? [...] i'll let you know the test results when i have some. same results -- can't initialise any drives. i think the example below points more directly to the issue but i'm pretty sure it is because the direct read from the disk does not return a valid disklabel. without a 'vinum' partition entry vinum spews. I have no idea how vinum does this or something else, but clearly something is not done the right way in vinum... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [ GEOM tests ] disklabel warnings and vinum drives lost
Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], n0go013 writ
es
:
On 04.10-15:40, fergus wrote:
On 04.10-14:20, Poul-Henning Kamp wrote:
[...]
I suspect vinum uses this sysctl to get an inventory of disks in
the system, so can I get you to try again making sure you have
rev. 1.20 of src/sys/geom/geom_disk.c ?
[...]
i'll let you know the test results when i have some.
same results -- can't initialise any drives. i think the example below
points more directly to the issue but i'm pretty sure it is because the
direct read from the disk does not return a valid disklabel. without a
'vinum' partition entry vinum spews.
I have no idea how vinum does this or something else, but clearly
something is not done the right way in vinum...
vinum is so much unbelievable stuff in it. Consider this stuff:
sys/dev/vinum/vinumio.c:
/* Find the device */
if (bcmp(dname, ad, 2) == 0) /* IDE disk */
devmajor = 116;
else if (bcmp(dname, wd, 2) == 0) /* IDE disk */
devmajor = 3;
else if (bcmp(dname, da, 2) == 0)
devmajor = 13;
else if (bcmp(dname, vn, 2) == 0)
devmajor = 43;
else if (bcmp(dname, md, 2) == 0)
devmajor = 95;
else if (bcmp(dname, ar, 2) == 0)
devmajor = 157;
else if (bcmp(dname, amrd, 4) == 0) {
devmajor = 133;
dname += 2;
} else if (bcmp(dname, mlxd, 4) == 0) {
devmajor = 131;
dname += 2;
} else if (bcmp(dname, idad, 4) == 0) {
devmajor = 109;
dname += 2;
} else if (bcmp(dname, twed, 4) == 0) { /* 3ware raid */
devmajor = 147;
dname += 2;
} else
return ENODEV;
dname += 2; /* point past */
It goes *way* downhill from there. :-(
Guess what happens when a new driver is added to the kernel?
Guess what happens if somebody doesn't use the official naming in /dev?
This crud has *got* to be taken out and shot, then reworked to do it
properly.
Oh, and lets not talk about trying to run vinum on partition schemes that
do not even *have* disklabels.
Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
All of this is for nothing if we don't go to the stars - JMS/B5
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: [ GEOM tests ] disklabel warnings and vinum drives lost
* Peter Wemm ([EMAIL PROTECTED]) wrote: vinum is so much unbelievable stuff in it. Consider this stuff: sys/dev/vinum/vinumio.c: [Big ugly if/else fallthrough snipped] Ick... Which sick person wrote that? switch() and cpp macros usually do wonders in cases like these in terms of readability/maintainability at least. It goes *way* downhill from there. :-( And I stay away from vinum just a little longer after having seen and verified this... [snip] This crud has *got* to be taken out and shot, then reworked to do it properly. Amen! (and no, I'm not volunteering. I don't mind cleaning up code, but there are limits to what crud I touch) Cheers, Emiel -- When the English language gets in my way, I walk over it. -- Billy Sunday To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [ GEOM tests ] disklabel warnings and vinum drives lost
Emiel Kollof wrote: * Peter Wemm ([EMAIL PROTECTED]) wrote: vinum is so much unbelievable stuff in it. Consider this stuff: sys/dev/vinum/vinumio.c: [ ... ] This crud has *got* to be taken out and shot, then reworked to do it properly. Amen! (and no, I'm not volunteering. I don't mind cleaning up code, but there are limits to what crud I touch) FWIW: The comment right before that code is: /* * Yes, Bruce, I know this is horrible, but we * don't have a root file system when we first * try to do this. If you can come up with a * better solution, I'd really like it. I'm * just putting it in now to add ammuntion to * moving the system to devfs. */ ...basically, when devfs became default, the person who made it default did not maintain this code, when they converted everything else over to using it. The assumption here is that the devfs will be available to the system before the root is mounted transparently over it. This is also doable with an unmounted instance of the backing devfs, not yet mounted on /dev, if a transparent mount of / over top of a preexiting / - /dev is not supported (i.e. devfs is mounted on /dev on the root FS, rather than the root FS being mounted on a backing node on which defvfs is already mounted on /, and the devices showing through as if they were on /). I think the major problem with the Vinum code is that it isn't very readable in an 80 column editor window with 8 column tabs, but that's pretty much the worst you can say about it, other than the code has not been maintained by the people changing subsystems out from under it. Another alternative is to disable support for mounting vinum plexes as the root filesystem, which is what this code supposedly supports. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [ GEOM tests ] disklabel warnings and vinum drives lost
Terry Lambert wrote: Emiel Kollof wrote: * Peter Wemm ([EMAIL PROTECTED]) wrote: vinum is so much unbelievable stuff in it. Consider this stuff: sys/dev/vinum/vinumio.c: [ ... ] This crud has *got* to be taken out and shot, then reworked to do it properly. Amen! (and no, I'm not volunteering. I don't mind cleaning up code, but the re are limits to what crud I touch) FWIW: The comment right before that code is: /* * Yes, Bruce, I know this is horrible, but we * don't have a root file system when we first * try to do this. If you can come up with a * better solution, I'd really like it. I'm * just putting it in now to add ammuntion to * moving the system to devfs. */ ...basically, when devfs became default, the person who made it default did not maintain this code, when they converted everything else over to using it. The assumption here is that the devfs will be available to the system before the root is mounted transparently over it. Actually no, this is only used *after* root is mounted. This is also doable with an unmounted instance of the backing devfs, not yet mounted on /dev, if a transparent mount of / over top of a preexiting / - /dev is not supported (i.e. devfs is mounted on /dev on the root FS, rather than the root FS being mounted on a backing node on which defvfs is already mounted on /, and the devices showing through as if they were on /). I think the major problem with the Vinum code is that it isn't very readable in an 80 column editor window with 8 column tabs, but that's pretty much the worst you can say about it, other than the code has not been maintained by the people changing subsystems out from under it. Another alternative is to disable support for mounting vinum plexes as the root filesystem, which is what this code supposedly supports. Nope. Vinum doesn't support booting with a plex as a root file system. I can't quite say that I understand what this is for though. namei() etc are perfectly usable at this point. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [ GEOM tests ] disklabel warnings and vinum drives lost
On Fri, 4 Oct 2002, Terry Lambert wrote: I think the major problem with the Vinum code is that it isn't very readable in an 80 column editor window with 8 column tabs, but that's pretty much the worst you can say about it, other than the code has not been maintained by the people changing subsystems out from under it. This changing APIs out from under WORKING subsystems is something I'd like to have a ruling on -CORE from. Calling it bit-rot is how people have gotten away with stuff like that in the past but it really has to stop. If your new super nifty kernel code is so wonderful then you can take the time to not break existing code and to update it properly to your new API. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | For Great Justice! | ISO8802.5 4ever | To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: [ GEOM tests ] disklabel warnings and vinum drives lost
Terry Lambert wrote: Emiel Kollof wrote: * Peter Wemm ([EMAIL PROTECTED]) wrote: vinum is so much unbelievable stuff in it. Consider this stuff: sys/dev/vinum/vinumio.c: [ ... ] This crud has *got* to be taken out and shot, then reworked to do it properly. Amen! (and no, I'm not volunteering. I don't mind cleaning up code, but the re are limits to what crud I touch) FWIW: The comment right before that code is: /* * Yes, Bruce, I know this is horrible, but we * don't have a root file system when we first * try to do this. If you can come up with a * better solution, I'd really like it. I'm * just putting it in now to add ammuntion to * moving the system to devfs. */ ...basically, when devfs became default, the person who made it default did not maintain this code, when they converted everything else over to using it. The assumption here is that the devfs will be available to the system before the root is mounted transparently over it. Actually no, this is only used *after* root is mounted. This is also doable with an unmounted instance of the backing devfs, not yet mounted on /dev, if a transparent mount of / over top of a preexiting / - /dev is not supported (i.e. devfs is mounted on /dev on the root FS, rather than the root FS being mounted on a backing node on which defvfs is already mounted on /, and the devices showing through as if they were on /). I think the major problem with the Vinum code is that it isn't very readable in an 80 column editor window with 8 column tabs, but that's pretty much the worst you can say about it, other than the code has not been maintained by the people changing subsystems out from under it. Another alternative is to disable support for mounting vinum plexes as the root filesystem, which is what this code supposedly supports. Nope. Vinum doesn't support booting with a plex as a root file system. I can't quite say that I understand what this is for though. namei() etc are perfectly usable at this point. Cheers, -Peter Gee, RAIDframe supports using an array as the root filesystem, and it didn't need a goofy list like that. Autoconfiguration works with any disk subsystem that registers properly with the disk layer (of course, this is in the non-GEOM world). shrug Read the Developer's Status Report. Coming soon to a cvs mirror near you. Scott To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [ GEOM tests ] disklabel warnings and vinum drives lost
On Fri, 4 Oct 2002, Terry Lambert wrote:
The assumption here is that the devfs will be available to the system
before the root is mounted transparently over it. This is also doable
with an unmounted instance of the backing devfs, not yet mounted on
/dev, if a transparent mount of / over top of a preexiting / - /dev is
not supported (i.e. devfs is mounted on /dev on the root FS, rather than
the root FS being mounted on a backing node on which defvfs is already
mounted on /, and the devices showing through as if they were on /).
Actually, no -- Vinum doesn't know how to do that--the device name used in
this code originates in a userland ioctl() configuration call for Vinum.
However, here's a patch that makes Vinum use namei() to rely on devfs to
locate requested devices instead of parsing the device name and guessing
the device number (incorrectly with GEOM). Unfortunately, I almost
immediately run into a divide by zero due to a zero sector size. Jeff
Roberson mentioned to me he had a fix for this bug that he sent to Greg,
but that was never committed.
Index: vinumio.c
===
RCS file: /home/ncvs/src/sys/dev/vinum/vinumio.c,v
retrieving revision 1.75
diff -u -r1.75 vinumio.c
--- vinumio.c 21 Aug 2002 23:39:51 - 1.75
+++ vinumio.c 5 Oct 2002 00:03:09 -
@@ -50,92 +50,25 @@
int
open_drive(struct drive *drive, struct thread *td, int verbose)
{
-int devmajor; /* major devs for disk
device */
-int devminor; /* minor devs for disk
device */
-int unit;
-char *dname;
+struct nameidata nd;
struct cdevsw *dsw;/* pointer to
cdevsw entry */
+int error;
-if (bcmp(drive-devicename, /dev/, 5)) /* device name doesn't
start with /dev */
- return ENOENT; /* give up */
if (drive-flags VF_OPEN)/* open already, */
return EBUSY; /* don't do it again */
-/*
- * Yes, Bruce, I know this is horrible, but we
- * don't have a root filesystem when we first
- * try to do this. If you can come up with a
- * better solution, I'd really like it. I'm
- * just putting it in now to add ammuntion to
- * moving the system to devfs.
- */
-dname = drive-devicename[5];
-drive-dev = NULL; /* no device yet */
-
-/* Find the device */
-if (bcmp(dname, ad, 2) == 0) /* IDE disk */
- devmajor = 116;
-else if (bcmp(dname, wd, 2) == 0)/* IDE disk */
- devmajor = 3;
-else if (bcmp(dname, da, 2) == 0)
- devmajor = 13;
-else if (bcmp(dname, vn, 2) == 0)
- devmajor = 43;
-else if (bcmp(dname, md, 2) == 0)
- devmajor = 95;
-else if (bcmp(dname, ar, 2) == 0)
-devmajor = 157;
-else if (bcmp(dname, amrd, 4) == 0) {
- devmajor = 133;
- dname += 2;
-} else if (bcmp(dname, mlxd, 4) == 0) {
- devmajor = 131;
- dname += 2;
-} else if (bcmp(dname, idad, 4) == 0) {
- devmajor = 109;
- dname += 2;
-} else if (bcmp(dname, twed, 4) == 0) { /* 3ware raid */
- devmajor = 147;
- dname += 2;
-} else
- return ENODEV;
-dname += 2;/* point past */
-
-/*
- * Found the device. We can expect one of
- * two formats for the rest: a unit number,
- * then either a partition letter for the
- * compatiblity partition (e.g. h) or a
- * slice ID and partition (e.g. s2e).
- * Create a minor number for each of them.
- */
-unit = 0;
-while ((*dname = '0') /* unit number */
-(*dname = '9')) {
- unit = unit * 10 + *dname - '0';
- dname++;
+NDINIT(nd, LOOKUP, FOLLOW | LOCKLEAF, UIO_SYSSPACE, drive-devicename,
+curthread);
+error = namei(nd);
+if (error)
+ return (error);
+if (!vn_isdisk(nd.ni_vp, error)) {
+ NDFREE(nd, 0);
+ return (error);
}
+drive-dev = udev2dev(nd.ni_vp-v_rdev-si_udev, 0);
+NDFREE(nd, 0);
-if (*dname == 's') { /* slice */
- if (((dname[1] '1') || (dname[1] '4')) /* invalid slice */
- ||((dname[2] 'a') || (dname[2] 'h'))) /* or invalid partition */
- return ENODEV;
- devminor = ((unit 31) 3) /* unit */
- +(dname[2] - 'a') /* partition */
- +((dname[1] - '0' + 1) 16) /* slice */
- +((unit ~31) 16); /* high-order unit bits */
-} else { /*
Re: [ GEOM tests ] disklabel warnings and vinum drives lost
On Friday, 4 October 2002 at 14:11:57 -0700, Peter Wemm wrote: Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], n0go013 writ es : On 04.10-15:40, fergus wrote: On 04.10-14:20, Poul-Henning Kamp wrote: [...] I suspect vinum uses this sysctl to get an inventory of disks in the system, so can I get you to try again making sure you have rev. 1.20 of src/sys/geom/geom_disk.c ? [...] i'll let you know the test results when i have some. same results -- can't initialise any drives. i think the example below points more directly to the issue but i'm pretty sure it is because the direct read from the disk does not return a valid disklabel. without a 'vinum' partition entry vinum spews. I have no idea how vinum does this or something else, but clearly something is not done the right way in vinum... vinum is so much unbelievable stuff in it. Consider this stuff: sys/dev/vinum/vinumio.c: /* Find the device */ if (bcmp(dname, ad, 2) == 0) /* IDE disk */ devmajor = 116; You missed the lines in front: /* * Yes, Bruce, I know this is horrible, but we * don't have a root filesystem when we first * try to do this. If you can come up with a * better solution, I'd really like it. I'm * just putting it in now to add ammuntion to * moving the system to devfs. */ It goes *way* downhill from there. :-( Really? I thought that was the worst of the lot. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [ GEOM tests ] disklabel warnings and vinum drives lost
On Friday, 4 October 2002 at 16:03:24 -0700, Peter Wemm wrote: Terry Lambert wrote: Emiel Kollof wrote: * Peter Wemm ([EMAIL PROTECTED]) wrote: vinum is so much unbelievable stuff in it. Consider this stuff: sys/dev/vinum/vinumio.c: [ ... ] This crud has *got* to be taken out and shot, then reworked to do it properly. Amen! (and no, I'm not volunteering. I don't mind cleaning up code, but the re are limits to what crud I touch) FWIW: The comment right before that code is: /* * Yes, Bruce, I know this is horrible, but we * don't have a root file system when we first * try to do this. If you can come up with a * better solution, I'd really like it. I'm * just putting it in now to add ammuntion to * moving the system to devfs. */ ...basically, when devfs became default, the person who made it default did not maintain this code, when they converted everything else over to using it. The assumption here is that the devfs will be available to the system before the root is mounted transparently over it. Actually no, this is only used *after* root is mounted. Now. Vinum supported the root file system years ago, but there were objections to the code. This was a temporary hack which was supposed to go away quickly, but then there was some pressure for me to give up maintainership, so I did, and Vinum has had very little maintenance since. Another alternative is to disable support for mounting vinum plexes as the root filesystem, which is what this code supposedly supports. Nope. Vinum doesn't support booting with a plex as a root file system. I can't quite say that I understand what this is for though. namei() etc are perfectly usable at this point. It did. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [ GEOM tests ] disklabel warnings and vinum drives lost
On Fri, 4 Oct 2002, Robert Watson wrote: On Fri, 4 Oct 2002, Terry Lambert wrote: The assumption here is that the devfs will be available to the system before the root is mounted transparently over it. This is also doable with an unmounted instance of the backing devfs, not yet mounted on /dev, if a transparent mount of / over top of a preexiting / - /dev is not supported (i.e. devfs is mounted on /dev on the root FS, rather than the root FS being mounted on a backing node on which defvfs is already mounted on /, and the devices showing through as if they were on /). Actually, no -- Vinum doesn't know how to do that--the device name used in this code originates in a userland ioctl() configuration call for Vinum. However, here's a patch that makes Vinum use namei() to rely on devfs to locate requested devices instead of parsing the device name and guessing the device number (incorrectly with GEOM). Unfortunately, I almost immediately run into a divide by zero due to a zero sector size. Jeff Roberson mentioned to me he had a fix for this bug that he sent to Greg, but that was never committed. On the general topic of access to devices before a root has been found, Maxime Henrion [EMAIL PROTECTED] has done some interesting work on 'rootfs', a pseudofs used to bootstrap support for devfs, etc. In such an environment, Vinum and other consumers of devices would be able to rely on devfs access prior to the real root mount process. I'm not sure which pivotroot-like trick he's using, or whether he's doing the union thing to do the root re-mount. Presumably he has to be careful not to deadfs the devfs nodes in place before the real root turns up, etc. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [ GEOM tests ] disklabel warnings and vinum drives lost
On Friday, 4 October 2002 at 20:07:11 -0400, Robert Watson wrote: On Fri, 4 Oct 2002, Terry Lambert wrote: The assumption here is that the devfs will be available to the system before the root is mounted transparently over it. This is also doable with an unmounted instance of the backing devfs, not yet mounted on /dev, if a transparent mount of / over top of a preexiting / - /dev is not supported (i.e. devfs is mounted on /dev on the root FS, rather than the root FS being mounted on a backing node on which defvfs is already mounted on /, and the devices showing through as if they were on /). Actually, no -- Vinum doesn't know how to do that--the device name used in this code originates in a userland ioctl() configuration call for Vinum. However, here's a patch that makes Vinum use namei() to rely on devfs to locate requested devices instead of parsing the device name and guessing the device number (incorrectly with GEOM). Unfortunately, I almost immediately run into a divide by zero due to a zero sector size. Jeff Roberson mentioned to me he had a fix for this bug that he sent to Greg, but that was never committed. FWIW, I've never seen this code. The dates on the patch suggest that it was made in the last quarter of an hour: --- vinumio.c 21 Aug 2002 23:39:51 - 1.75 +++ vinumio.c 5 Oct 2002 00:03:09 - However: RCS file: /home/ncvs/src/sys/modules/vinum/Makefile,v revision 1.18 date: 2000/04/16 00:17:46; author: grog; state: Exp; lines: +1 -3 Remove MAINTAINER. Since that point, this particular file has had 5 updates, only one from me. Jeff's a committer; he can commit it himself if he wants. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [ GEOM tests ] disklabel warnings and vinum drives lost
Greg 'groggy' Lehey wrote: On Friday, 4 October 2002 at 16:03:24 -0700, Peter Wemm wrote: Terry Lambert wrote: Emiel Kollof wrote: * Peter Wemm ([EMAIL PROTECTED]) wrote: vinum is so much unbelievable stuff in it. Consider this stuff: sys/dev/vinum/vinumio.c: [ ... ] This crud has *got* to be taken out and shot, then reworked to do it properly. Amen! (and no, I'm not volunteering. I don't mind cleaning up code, but t he re are limits to what crud I touch) FWIW: The comment right before that code is: /* * Yes, Bruce, I know this is horrible, but we * don't have a root file system when we first * try to do this. If you can come up with a * better solution, I'd really like it. I'm * just putting it in now to add ammuntion to * moving the system to devfs. */ ...basically, when devfs became default, the person who made it default did not maintain this code, when they converted everything else over to using it. The assumption here is that the devfs will be available to the system before the root is mounted transparently over it. Actually no, this is only used *after* root is mounted. Now. Vinum supported the root file system years ago, but there were objections to the code. This was a temporary hack which was supposed to go away quickly, but then there was some pressure for me to give up maintainership, so I did, and Vinum has had very little maintenance since. I had a look around and couldn't find any real traces of it in the cvs history. I recall a patch being posted somewhere but do not remember it being committed for some reason (bootblock issues?). Another alternative is to disable support for mounting vinum plexes as the root filesystem, which is what this code supposedly supports. Nope. Vinum doesn't support booting with a plex as a root file system. I can't quite say that I understand what this is for though. namei() etc are perfectly usable at this point. It did. .. but not committed to FreeBSD as far as I can tell. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [ GEOM tests ] disklabel warnings and vinum drives lost
On Friday, 4 October 2002 at 20:21:29 -0400, Robert Watson wrote: On Fri, 4 Oct 2002, Robert Watson wrote: On Fri, 4 Oct 2002, Terry Lambert wrote: The assumption here is that the devfs will be available to the system before the root is mounted transparently over it. This is also doable with an unmounted instance of the backing devfs, not yet mounted on /dev, if a transparent mount of / over top of a preexiting / - /dev is not supported (i.e. devfs is mounted on /dev on the root FS, rather than the root FS being mounted on a backing node on which defvfs is already mounted on /, and the devices showing through as if they were on /). Actually, no -- Vinum doesn't know how to do that--the device name used in this code originates in a userland ioctl() configuration call for Vinum. However, here's a patch that makes Vinum use namei() to rely on devfs to locate requested devices instead of parsing the device name and guessing the device number (incorrectly with GEOM). Unfortunately, I almost immediately run into a divide by zero due to a zero sector size. Jeff Roberson mentioned to me he had a fix for this bug that he sent to Greg, but that was never committed. On the general topic of access to devices before a root has been found, Maxime Henrion [EMAIL PROTECTED] has done some interesting work on 'rootfs', a pseudofs used to bootstrap support for devfs, etc. In such an environment, Vinum and other consumers of devices would be able to rely on devfs access prior to the real root mount process. I'm not sure which pivotroot-like trick he's using, or whether he's doing the union thing to do the root re-mount. Presumably he has to be careful not to deadfs the devfs nodes in place before the real root turns up, etc. As I say, it was working in early 2000. Some details needed changing, and the work never got finished, but it wasn't very much work. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [ GEOM tests ] disklabel warnings and vinum drives lost
On Sat, 5 Oct 2002, Greg 'groggy' Lehey wrote: FWIW, I've never seen this code. The dates on the patch suggest that it was made in the last quarter of an hour: I didn't claim that this was his code. This was code I just wrote to address Vinum not finding the devices due to major/minor number changes. I was referring to a separate problem involving a zero'd sectorsize resulting in a divide by zero in the kernel, which Jeff reported experiencing and fixing previously. --- vinumio.c 21 Aug 2002 23:39:51 - 1.75 +++ vinumio.c 5 Oct 2002 00:03:09 - However: RCS file: /home/ncvs/src/sys/modules/vinum/Makefile,v revision 1.18 date: 2000/04/16 00:17:46; author: grog; state: Exp; lines: +1 -3 Remove MAINTAINER. Since that point, this particular file has had 5 updates, only one from me. Jeff's a committer; he can commit it himself if he wants. Hmm. Funny, I was paying more attention to the line in the MAINTAINER's file which seems to suggest you are the maintainer. :-) Given that you appear to have read this patch -- may I commit it since it appears to resolve the first of the nits I ran into using Vinum with GEOM? There appear to be more problems in the tubes, but this one seemed straight-forward enough, especially since the functionality this patch replaces seems not to be in the tree. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [ GEOM tests ] disklabel warnings and vinum drives lost
On Fri, 4 Oct 2002, Robert Watson wrote: On the general topic of access to devices before a root has been found, Maxime Henrion [EMAIL PROTECTED] has done some interesting work on 'rootfs', a pseudofs used to bootstrap support for devfs, etc. In such an environment, Vinum and other consumers of devices would be able to rely on devfs access prior to the real root mount process. I'm not sure which pivotroot-like trick he's using, or whether he's doing the union thing to do the root re-mount. Presumably he has to be careful not to deadfs the devfs nodes in place before the real root turns up, etc. The original devfs supported access from within the kernel before mounting root and devfs.. It's not rocket science. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [ GEOM tests ] disklabel warnings and vinum drives lost
On Friday, 4 October 2002 at 20:29:51 -0400, Robert Watson wrote: On Sat, 5 Oct 2002, Greg 'groggy' Lehey wrote: FWIW, I've never seen this code. The dates on the patch suggest that it was made in the last quarter of an hour: I didn't claim that this was his code. This was code I just wrote to address Vinum not finding the devices due to major/minor number changes. Ah, then I misunderstood. Sorry. I was referring to a separate problem involving a zero'd sectorsize resulting in a divide by zero in the kernel, which Jeff reported experiencing and fixing previously. Ah, yes, I recall seeing that one, I think. --- vinumio.c 21 Aug 2002 23:39:51 - 1.75 +++ vinumio.c 5 Oct 2002 00:03:09 - However: RCS file: /home/ncvs/src/sys/modules/vinum/Makefile,v revision 1.18 date: 2000/04/16 00:17:46; author: grog; state: Exp; lines: +1 -3 Remove MAINTAINER. Since that point, this particular file has had 5 updates, only one from me. Jeff's a committer; he can commit it himself if he wants. Hmm. Funny, I was paying more attention to the line in the MAINTAINER's file which seems to suggest you are the maintainer. :-) No, I just suggest that people bounce things off me before committing: vinum grogRecommends pre-commit review. Given that you appear to have read this patch -- may I commit it since it appears to resolve the first of the nits I ran into using Vinum with GEOM? Sure, you don't need my permission. But let me look at it more carefully. As I said, I have a number of changes which also get rid of this mess, and which were never committed. Let me take a look and get back to you. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [ GEOM tests ] disklabel warnings and vinum drives lost
* De: Julian Elischer [EMAIL PROTECTED] [ Data: 2002-10-04 ] [ Subjecte: Re: [ GEOM tests ] disklabel warnings and vinum drives lost ] On Fri, 4 Oct 2002, Robert Watson wrote: On the general topic of access to devices before a root has been found, Maxime Henrion [EMAIL PROTECTED] has done some interesting work on 'rootfs', a pseudofs used to bootstrap support for devfs, etc. In such an environment, Vinum and other consumers of devices would be able to rely on devfs access prior to the real root mount process. I'm not sure which pivotroot-like trick he's using, or whether he's doing the union thing to do the root re-mount. Presumably he has to be careful not to deadfs the devfs nodes in place before the real root turns up, etc. The original devfs supported access from within the kernel before mounting root and devfs.. It's not rocket science. A rootfs has many other ideal uses. Like spinning bits of the kernel off to userland, and having procfs exist, too. -- Juli Mallett [EMAIL PROTECTED] | FreeBSD: The Power To Serve Will break world for fulltime employment. | finger [EMAIL PROTECTED] http://people.FreeBSD.org/~jmallett/ | Support my FreeBSD hacking! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [ GEOM tests ] disklabel warnings and vinum drives lost
In message [EMAIL PROTECTED], Robe rt Watson writes: However, here's a patch that makes Vinum use namei() to rely on devfs to locate requested devices instead of parsing the device name and guessing the device number (incorrectly with GEOM). Unfortunately, I almost immediately run into a divide by zero due to a zero sector size. Jeff Roberson mentioned to me he had a fix for this bug that he sent to Greg, but that was never committed. The divide by zero problem seems to be caused by an interaction between two bugs: GEOM refuses to return the sector size because the flags passed to d_open in vinum's open_drive() do not include FREAD. Then vinum clobbers the ioctl's non-zero error code by calling close_drive() from init_drive(), so the latter ends up returning zero even though it failed. The next failure I get is: Can't write config to /dev/da1s1d, error 45 (EOPNOTSUPP) Ian To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [ GEOM tests ] disklabel warnings and vinum drives lost
[CCs trimmed]
The divide by zero problem seems to be caused by an interaction
between two bugs: GEOM refuses to return the sector size because
...
The next failure I get is:
Can't write config to /dev/da1s1d, error 45 (EOPNOTSUPP)
This turns out to be vinum doing a DIOCWLABEL to make the label
writable before writing its configuration, but GEOM does not support
that ioctl I presume. It should be safe to ignore these DIOCWLABEL
ioctl return values as the actual writing of the vinum data should
give a suitable error if making the label writable fails and is
important. The patch below is Robert's patch with all 3 other issues
fixed, and together, this seems to be enough to make vinum work
again.
Ian
Index: vinumio.c
===
RCS file: /dump/FreeBSD-CVS/src/sys/dev/vinum/vinumio.c,v
retrieving revision 1.75
diff -u -r1.75 vinumio.c
--- vinumio.c 21 Aug 2002 23:39:51 - 1.75
+++ vinumio.c 5 Oct 2002 02:40:18 -
@@ -50,92 +50,25 @@
int
open_drive(struct drive *drive, struct thread *td, int verbose)
{
-int devmajor; /* major devs for disk
device */
-int devminor; /* minor devs for disk
device */
-int unit;
-char *dname;
+struct nameidata nd;
struct cdevsw *dsw;/* pointer to
cdevsw entry */
+int error;
-if (bcmp(drive-devicename, /dev/, 5)) /* device name doesn't
start with /dev */
- return ENOENT; /* give up */
if (drive-flags VF_OPEN)/* open already, */
return EBUSY; /* don't do it again */
-/*
- * Yes, Bruce, I know this is horrible, but we
- * don't have a root filesystem when we first
- * try to do this. If you can come up with a
- * better solution, I'd really like it. I'm
- * just putting it in now to add ammuntion to
- * moving the system to devfs.
- */
-dname = drive-devicename[5];
-drive-dev = NULL; /* no device yet */
-
-/* Find the device */
-if (bcmp(dname, ad, 2) == 0) /* IDE disk */
- devmajor = 116;
-else if (bcmp(dname, wd, 2) == 0)/* IDE disk */
- devmajor = 3;
-else if (bcmp(dname, da, 2) == 0)
- devmajor = 13;
-else if (bcmp(dname, vn, 2) == 0)
- devmajor = 43;
-else if (bcmp(dname, md, 2) == 0)
- devmajor = 95;
-else if (bcmp(dname, ar, 2) == 0)
-devmajor = 157;
-else if (bcmp(dname, amrd, 4) == 0) {
- devmajor = 133;
- dname += 2;
-} else if (bcmp(dname, mlxd, 4) == 0) {
- devmajor = 131;
- dname += 2;
-} else if (bcmp(dname, idad, 4) == 0) {
- devmajor = 109;
- dname += 2;
-} else if (bcmp(dname, twed, 4) == 0) { /* 3ware raid */
- devmajor = 147;
- dname += 2;
-} else
- return ENODEV;
-dname += 2;/* point past */
-
-/*
- * Found the device. We can expect one of
- * two formats for the rest: a unit number,
- * then either a partition letter for the
- * compatiblity partition (e.g. h) or a
- * slice ID and partition (e.g. s2e).
- * Create a minor number for each of them.
- */
-unit = 0;
-while ((*dname = '0') /* unit number */
-(*dname = '9')) {
- unit = unit * 10 + *dname - '0';
- dname++;
-}
-
-if (*dname == 's') { /* slice */
- if (((dname[1] '1') || (dname[1] '4')) /* invalid slice */
- ||((dname[2] 'a') || (dname[2] 'h'))) /* or invalid partition */
- return ENODEV;
- devminor = ((unit 31) 3) /* unit */
- +(dname[2] - 'a') /* partition */
- +((dname[1] - '0' + 1) 16) /* slice */
- +((unit ~31) 16); /* high-order unit bits */
-} else { /* compatibility partition
*/
- if ((*dname 'a') || (*dname 'h')) /* or invalid partition */
- return ENODEV;
- devminor = (*dname - 'a') /* partition */
- +((unit 31) 3) /* unit */
- +((unit ~31) 16); /* high-order unit bits */
+NDINIT(nd, LOOKUP, FOLLOW | LOCKLEAF, UIO_SYSSPACE, drive-devicename,
+curthread);
+error = namei(nd);
+if (error)
+ return (error);
+if (!vn_isdisk(nd.ni_vp, error)) {
+ NDFREE(nd, 0);
+ return (error);
}
+drive-dev = udev2dev(nd.ni_vp-v_rdev-si_udev, 0);
+
Re: [ GEOM tests ] disklabel warnings and vinum drives lost
On Sat, 5 Oct 2002, Ian Dowse wrote:
The divide by zero problem seems to be caused by an interaction
between two bugs: GEOM refuses to return the sector size because
...
The next failure I get is:
Can't write config to /dev/da1s1d, error 45 (EOPNOTSUPP)
This turns out to be vinum doing a DIOCWLABEL to make the label writable
before writing its configuration, but GEOM does not support that ioctl I
presume. It should be safe to ignore these DIOCWLABEL ioctl return
values as the actual writing of the vinum data should give a suitable
error if making the label writable fails and is important. The patch
below is Robert's patch with all 3 other issues fixed, and together,
this seems to be enough to make vinum work again.
Wonderful. I just committed a fix so that vinum.ko can be unloaded
without a panic when WITNESS is present. I'll give the combined patch a
spin on my crashbox and see if it does the trick here. Thanks!
Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED] Network Associates Laboratories
Index: vinumio.c
===
RCS file: /dump/FreeBSD-CVS/src/sys/dev/vinum/vinumio.c,v
retrieving revision 1.75
diff -u -r1.75 vinumio.c
--- vinumio.c 21 Aug 2002 23:39:51 - 1.75
+++ vinumio.c 5 Oct 2002 02:40:18 -
@@ -50,92 +50,25 @@
int
open_drive(struct drive *drive, struct thread *td, int verbose)
{
-int devmajor;/* major devs for disk
device */
-int devminor;/* minor devs for disk
device */
-int unit;
-char *dname;
+struct nameidata nd;
struct cdevsw *dsw; /* pointer to
cdevsw entry */
+int error;
-if (bcmp(drive-devicename, /dev/, 5)) /* device name doesn't
start with /dev */
- return ENOENT; /* give up */
if (drive-flags VF_OPEN) /* open already, */
return EBUSY; /* don't do it again */
-/*
- * Yes, Bruce, I know this is horrible, but we
- * don't have a root filesystem when we first
- * try to do this. If you can come up with a
- * better solution, I'd really like it. I'm
- * just putting it in now to add ammuntion to
- * moving the system to devfs.
- */
-dname = drive-devicename[5];
-drive-dev = NULL; /* no device yet */
-
-/* Find the device */
-if (bcmp(dname, ad, 2) == 0) /* IDE disk */
- devmajor = 116;
-else if (bcmp(dname, wd, 2) == 0) /* IDE disk */
- devmajor = 3;
-else if (bcmp(dname, da, 2) == 0)
- devmajor = 13;
-else if (bcmp(dname, vn, 2) == 0)
- devmajor = 43;
-else if (bcmp(dname, md, 2) == 0)
- devmajor = 95;
-else if (bcmp(dname, ar, 2) == 0)
-devmajor = 157;
-else if (bcmp(dname, amrd, 4) == 0) {
- devmajor = 133;
- dname += 2;
-} else if (bcmp(dname, mlxd, 4) == 0) {
- devmajor = 131;
- dname += 2;
-} else if (bcmp(dname, idad, 4) == 0) {
- devmajor = 109;
- dname += 2;
-} else if (bcmp(dname, twed, 4) == 0) { /* 3ware raid */
- devmajor = 147;
- dname += 2;
-} else
- return ENODEV;
-dname += 2; /* point past */
-
-/*
- * Found the device. We can expect one of
- * two formats for the rest: a unit number,
- * then either a partition letter for the
- * compatiblity partition (e.g. h) or a
- * slice ID and partition (e.g. s2e).
- * Create a minor number for each of them.
- */
-unit = 0;
-while ((*dname = '0') /* unit number */
-(*dname = '9')) {
- unit = unit * 10 + *dname - '0';
- dname++;
-}
-
-if (*dname == 's') { /* slice */
- if (((dname[1] '1') || (dname[1] '4')) /* invalid slice */
- ||((dname[2] 'a') || (dname[2] 'h'))) /* or invalid partition */
- return ENODEV;
- devminor = ((unit 31) 3) /* unit */
- +(dname[2] - 'a') /* partition */
- +((dname[1] - '0' + 1) 16) /* slice */
- +((unit ~31) 16); /* high-order unit bits */
-} else { /* compatibility partition
*/
- if ((*dname 'a') || (*dname 'h')) /* or invalid partition */
- return ENODEV;
- devminor = (*dname - 'a') /* partition */
- +((unit 31) 3) /* unit */
- +((unit
Re: [ GEOM tests ] disklabel warnings and vinum drives lost
On Saturday, 5 October 2002 at 4:08:19 +0100, Ian Dowse wrote: [CCs trimmed] The divide by zero problem seems to be caused by an interaction between two bugs: GEOM refuses to return the sector size because ... The next failure I get is: Can't write config to /dev/da1s1d, error 45 (EOPNOTSUPP) This turns out to be vinum doing a DIOCWLABEL to make the label writable before writing its configuration, but GEOM does not support that ioctl I presume. It should be safe to ignore these DIOCWLABEL ioctl return values as the actual writing of the vinum data should give a suitable error if making the label writable fails and is important. The patch below is Robert's patch with all 3 other issues fixed, and together, this seems to be enough to make vinum work again. OK, I've taken a look at this, and it looks pretty much like what I have in the pipeline. Yours is presumably tested, so that seems the way to go. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [ GEOM tests ] disklabel warnings and vinum drives lost
On Sat, 5 Oct 2002, Ian Dowse wrote: The divide by zero problem seems to be caused by an interaction between two bugs: GEOM refuses to return the sector size because ... The next failure I get is: Can't write config to /dev/da1s1d, error 45 (EOPNOTSUPP) This turns out to be vinum doing a DIOCWLABEL to make the label writable before writing its configuration, but GEOM does not support that ioctl I presume. It should be safe to ignore these DIOCWLABEL ioctl return values as the actual writing of the vinum data should give a suitable error if making the label writable fails and is important. The patch below is Robert's patch with all 3 other issues fixed, and together, this seems to be enough to make vinum work again. Ok -- I went ahead and booted and ran the merged patch on my testbox, and Vinum is up and running fine with GEOM. I think we're set to commit -- do you want to, or shall I? Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [ GEOM tests ] disklabel warnings and vinum drives lost
On Saturday, 5 October 2002 at 4:08:19 +0100, Ian Dowse wrote:
[CCs trimmed]
The divide by zero problem seems to be caused by an interaction
between two bugs: GEOM refuses to return the sector size because
...
The next failure I get is:
Can't write config to /dev/da1s1d, error 45 (EOPNOTSUPP)
This turns out to be vinum doing a DIOCWLABEL to make the label
writable before writing its configuration, but GEOM does not support
that ioctl I presume. It should be safe to ignore these DIOCWLABEL
ioctl return values as the actual writing of the vinum data should
give a suitable error if making the label writable fails and is
important. The patch below is Robert's patch with all 3 other issues
fixed, and together, this seems to be enough to make vinum work
again.
@@ -678,20 +615,18 @@
if ((drive-state != drive_unallocated)
(drive-state != drive_referenced)) { /* and it's a real drive
*/
wlabel_on = 1; /* enable writing the
label */
- error = (*devsw(drive-dev)-d_ioctl) (drive-dev, /* make the
label writeable */
+ (void) (*devsw(drive-dev)-d_ioctl) (drive-dev, /* make the
label writeable */
DIOCWLABEL,
(caddr_t) wlabel_on,
FWRITE,
curthread);
- if (error == 0)
- error = write_drive(drive, (char *) vhdr, VINUMHEADERLEN,
VINUM_LABEL_OFFSET);
+ error = write_drive(drive, (char *) vhdr, VINUMHEADERLEN,
VINUM_LABEL_OFFSET);
if (error == 0)
error = write_drive(drive, config, MAXCONFIG,
VINUM_CONFIG_OFFSET); /* first config copy */
if (error == 0)
error = write_drive(drive, config, MAXCONFIG,
VINUM_CONFIG_OFFSET + MAXCONFIG); /* second copy */
wlabel_on = 0; /* enable writing the
label */
- if (error == 0)
- error = (*devsw(drive-dev)-d_ioctl) (drive-dev, /* make the
label non-writeable again */
+ (void) (*devsw(drive-dev)-d_ioctl) (drive-dev, /* make the
label non-writeable again */
DIOCWLABEL,
(caddr_t) wlabel_on,
FWRITE,
I don't know how GEOM handles disk labels, though we've heard a lot
about changes. It's possible that this code is now completely
redundant. It's preparing to write at offset 8 sectors and on from
the beginning of the partition; it would be worth checking what
happens if you just remove the whole disk label writeable stuff.
Greg
--
See complete headers for address and phone numbers
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: [ GEOM tests ] disklabel warnings and vinum drives lost
In message [EMAIL PROTECTED], Ian Dowse writes: In message [EMAIL PROTECTED], Robe rt Watson writes: However, here's a patch that makes Vinum use namei() to rely on devfs to locate requested devices instead of parsing the device name and guessing the device number (incorrectly with GEOM). Unfortunately, I almost immediately run into a divide by zero due to a zero sector size. Jeff Roberson mentioned to me he had a fix for this bug that he sent to Greg, but that was never committed. The divide by zero problem seems to be caused by an interaction between two bugs: Make that _three_ bugs: vinum opens devices directly at the cdevsw level, bypassing in the process the vnodes and specfs. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [ GEOM tests ] disklabel warnings and vinum drives lost
In message [EMAIL PROTECTED], Greg 'groggy' Lehey writes: I don't know how GEOM handles disk labels, though we've heard a lot about changes. It's possible that this code is now completely redundant. It's preparing to write at offset 8 sectors and on from the beginning of the partition; it would be worth checking what happens if you just remove the whole disk label writeable stuff. In GEOM you will only find disklabels on disks which have them. That means that there will not be disklabels on sparc64 (unless somebody decides to put them there for obscure reasons). Struct disklabel is being demoted from generic communicator of disk geometry parameters because it doesn't do a very good job at it: it's 32bit. And rather than invent a new proprietry 64bit format, we have disbanded the idea in toto, and treated the four real-life geometry parameters individually. mediasize sectorsize fwsectors fwheads The last two are only to be used to read/write firmware/bootstrap compatible magic data on the disks. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
