Missing feature in config(8)
Fred L. Templin
templin at psuvax1.UUCP
Fri May 31 23:31:03 AEST 1985
There is a "missing feature" in config(8) which has to do with the
way the iostat(1) and vmstat(1) utilities get their information for disks.
On one of our VAX 11/780's, we have eight disks connected to two controllers;
one per Massbus Adapter. Our system configuration file looks like:
.
.
.
controller mba0 at nexus ?
controller mba1 at nexus ?
controller mba2 at nexus ?
controller uba0 at nexus ?
master ht0 at mba? drive 0
tape tu0 at ht0 slave 0
disk hp0 at mba0 drive 0
disk hp1 at mba2 drive 1
disk hp2 at mba0 drive 2
disk hp3 at mba0 drive 3
disk hp4 at mba2 drive 4
disk hp5 at mba2 drive 5
disk hp6 at mba? drive 7
disk hp7 at mba2 drive 0
.
.
.
During normal operation, we only have partitions of hp0, hp1, hp3 and
hp4 mounted; the remaining drives are mounted by two other VAXes which share
these controllers. The problem we had was that when "config" builds the
"ioconf.c" file, it sets the "mi_dk" flag in the "mbdinit" table for EVERY
disk listed in the configuration file, like so:
.
.
.
struct mba_device mbdinit[] = {
/* Device, Unit, Mba, Drive, Dk */
{ &htdriver, 0, '?', 0, 0 },
{ &hpdriver, 0, 0, 0, 1 },
{ &hpdriver, 1, 2, 1, 1 },
{ &hpdriver, 2, 0, 2, 1 },
{ &hpdriver, 3, 0, 3, 1 },
{ &hpdriver, 4, 2, 4, 1 },
{ &hpdriver, 5, 2, 5, 1 },
{ &hpdriver, 6, '?', 7, 1 },
{ &hpdriver, 7, 2, 0, 1 },
0
};
.
.
.
Now, at boot time, when the autoconf.c routine "configure" probes
each nexus for devices, it picks out the first "DK_NDRIVE" (DK_NDRIVE = 4)
entries in the mbdinit structure which have the "mi_dk" flag set and assigns
them "dk" entries. In our case, hp0, hp2, hp3 and hp6 will be picked, since
"configure" will find them first. This messes up the utilities "vmstat" and
"iostat", since they use the "dk" entries to display information for the
disks, and "configure" chose the wrong ones!
As a solution to the problem, I added an extra flag to the production
for disks in the parser to indicate which disks are to be given "dk" entries.
The files I modified were "/usr/src/etc/config/config.y" and "config.l" and
the diffs are:
*** config.y Mon Apr 29 14:01:53 1985
--- config.old.y Tue Dec 4 13:39:13 1984
***************
*** 24,26
%token HZ
- %token IOSTAT
%token IDENT
--- 24,25 -----
%token HZ
%token IDENT
***************
*** 363,365
DISK Dev_name Dev_info Int_spec
! = { cur.d_type = DEVICE; } |
CONTROLLER Dev_name Dev_info Int_spec
--- 362,364 -----
DISK Dev_name Dev_info Int_spec
! = { cur.d_dk = 1; cur.d_type = DEVICE; } |
CONTROLLER Dev_name Dev_info Int_spec
***************
*** 437,440
= { cur.d_pri = $2; } |
- IOSTAT
- = { cur.d_dk = 1; } |
/* lambda */
--- 436,437 -----
= { cur.d_pri = $2; } |
/* lambda */
*** config.l Mon Apr 29 14:02:50 1985
--- config.old.l Tue Oct 18 18:44:46 1983
***************
*** 32,34
{ "ident", IDENT },
- { "iostat", IOSTAT },
{ "machine", MACHINE },
--- 32,33 -----
{ "ident", IDENT },
{ "machine", MACHINE },
Now, our system specification file looks like:
.
.
.
disk hp0 at mba0 drive 0 iostat
disk hp1 at mba2 drive 1 iostat
disk hp2 at mba0 drive 2
disk hp3 at mba0 drive 3 iostat
disk hp4 at mba2 drive 4 iostat
disk hp5 at mba2 drive 5
disk hp6 at mba? drive 7
disk hp7 at mba2 drive 0
.
.
.
and config builds ioconf.c as follows:
.
.
.
struct mba_device mbdinit[] = {
/* Device, Unit, Mba, Drive, Dk */
{ &htdriver, 0, '?', 0, 0 },
{ &htdriver, 1, '?', 0, 0 },
{ &hpdriver, 0, 0, 0, 1 },
{ &hpdriver, 1, 2, 1, 1 },
{ &hpdriver, 2, 0, 2, 0 },
{ &hpdriver, 3, 0, 3, 1 },
{ &hpdriver, 4, 2, 4, 1 },
{ &hpdriver, 5, 2, 5, 0 },
{ &hpdriver, 6, '?', 7, 0 },
{ &hpdriver, 7, 2, 0, 0 },
0
};
.
.
.
Now, at boot time, "configure" will pick up the correct disks to be monitored.
The trouble with this approach is that failing to append the "iostat"
flag to your disk specifications leaves you with NO disks monitored, and
having to remember to use the "iostat" flag all the time is a pain in the neck
if you've never had to worry about this problem before. If anyone can suggest
a better solution, please mail to me or post to the net. Thanks!
--
---------------------------------------
Fred L. Templin
Penn State Computer Science Dept.
303 Whitmore Lab
University Park, Pa. 16802
{akgua,allegra,ihnp4}!psuvax1!templin
---------------------------------------
More information about the Comp.bugs.4bsd.ucb-fixes
mailing list