Hello System Admins,
Thanks very much to the following for taking the time to
send me much helpful information:
"Clegg, Larry" <Larry_Clegg_at_intuit.com>
Joseph Thvedt <JTHVEDT_at_larsondoors.com>
"Dr. Tom Blinn" <tpb_at_doctor.zk3.dec.com>
simon.millard_at_barclays.co.uk
sapplega_at_cityutil.com
Udo de Boer <Udo.de.boer_at_live.demon.nl>
alan_at_nabeth.cxo.dec.com
and also, the folks at Compaq technical support
According to the replies I received: Starting with version
4 of Tru64 it is no longer necessary to configure disk devices
into the kernel. Some referred to this as Dynamic Device
Recognition. My AlphaServer DS20 came with a KZPAC-AA
RAID controller (a single channel SWXCR / backplane type disk
controller), so if I want to query the running system for a list
of the disk devices that it knows about, I'll have to forget
about using the old uerf utility and instead use other methods.
As long as you've run the RCU (RAID Config Utility) to define
the logical drives you want, and then MAKEDEV to put them in
the /dev directory, you can then "see" them with these other
methods. Only the SWXCR controller needs to be configured into
the kernel. Disks offered to the operating system from a SWXCR
show up as "re" devices, instead of "rz" devices that I'm
familiar with. The man pages on re and rz offer some somewhat
dated info. One purpose of using intelligent controllers like
the SWXCR is to let the controller itself do all the i/o and
error management that it can without bothering the operating
system.
Other methods of querying the running system about its devices
include the "swxcrmgr" GUI utility, DECevent, Compaq Analyze,
and the CDE on the console. The swxcrmgr GUI ships on diskette
with the controller/subsystem. DECevent handles scsi disk info
better than Compaq Analyze and can be gotten from
http://www.support.compaq.com/svctools/decevent/. To use the CDE
to get the disk info, click the Application Manager (the tool
drawer icon), then System_Admin, then Configuration, then DISK.
If anyone knows of other online utilities to gather disk info,
I'll post a second SUMMARY.
Great list folks! Thanks for enlightening me.
Paul Youngblood
--------------------------------------------------------
--------original posting--------------------------------
--------------------------------------------------------
Hello System Admins,
How is is possible that I can access and use disks on a system whose
kernel has not been configured to "know" about them?
I've received a DS20 with a single-channel raid controller, seven
storageworks disks, and factory-installed Tru64 v4.0f. The kernel's
configuration file showed these disks:
# grep disk /sys/conf/MYSYSTEM
device disk re0 at xcr0 drive 0
device disk fd0 at fdi0 drive 0
When I boot using the kernel that shipped with the system, the
disk re0 (a JBOD) is the only "re" type disk scrolling across the
screen (during the boot sequence). I ran the Raid Config Utility
to define the other JBOD disks to the controller (re1, re2, re3, etc),
then ran MAKEDEV to create their device files in /dev. Just for the
heck of it (and BEFORE I added additional disk entries to the kernel
config file to build a new kernel) I tried using disklabel, mkfdmn,
mkfset, and mount to one (re1) of these "unknown" disks. To my
surprise all of these commands worked. Even writing files to the disk
was no problem.
Afterwards, I booted the generic kernel and ran sizer to get what it
thought the entries should be for those disks. I added them to the
system config file (/sys/conf/MYSYSTEM) and used it to generate a new
kernel. Now, of course, the new disks show up on the console during
bootup. Here are the disk entries in the updated config file:
# grep disk E2MAIL
device disk re0 at xcr0 drive 0
device disk re1 at xcr0 drive 1
device disk re2 at xcr0 drive 2
device disk re3 at xcr0 drive 3
device disk re4 at xcr0 drive 4
device disk re5 at xcr0 drive 5
device disk fd0 at fdi0 drive 0
I'm going to do a full install of the os later to tailor it the way
we like it, but I wanted to learn a few things first. I would really
appreciate it if any of you could enlighten me about this, and I'll
certainly submit a SUMMARY. Thank you for your attention.
Paul Youngblood
University of Alabama in Huntsville
Received on Wed Jul 19 2000 - 23:45:43 NZST