[net.bugs.4bsd] Missing feature in config

templin@psuvax1.UUCP (Fred L. Templin) (05/31/85)

	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
---------------------------------------

kupfer@ucbvax.ARPA (Mike Kupfer) (06/08/85)

In article <1653@psuvax1.UUCP> templin@psuvax1.UUCP (Fred L. Templin) writes:
>	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.  
> ...
>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!

A more general problem is that if your system really uses more than 4
disks, you can only monitor 4 of them with any one kernel.  Also,
iostat and vmstat know in 4.2 that there are only 4 instrumented disks.

The iostat and vmstat that will come with 4.3 let you specify arbitrary
disks (up to 4 for any invocation of the program, for formatting
reasons).  Alas, DK_NDRIVE is still stuck at 4, so 4.3 will still have
the "4 instrumented disks per kernel" limit.  Ideally, of course, the
kernel should instrument every disk that makes it through
auto-configuration.  Maybe next time...
-- 
Mike Kupfer
kupfer@ucb-arpa or kupfer@Berkeley
...!ucbvax!kupfer
``You can tell the pioneers by the arrows in their backs.''