Thank you to
and (esp.) email@example.com
It appears I was doing everything ok.
No one thinks there is any risk doing drvconfig while the system is in production.
The procedure is generally agreed that after adding a disk, doing
drvconfig; devlinks; disks is what is required.
One suggestion was that drvconfig ought be drvconfig -i sd.
The "OPEN FAILED" message is correct, meaning that there are no structures in place ( in /devices etc) to identify this disk.
Thanks to everyone who helped.
[mailto:firstname.lastname@example.org]On Behalf Of Rolf
Sent: Wednesday, March 29, 2000 6:09 PM
To: 'sun managers'
Subject: Adding disks to Sparc Storage Array.
Yesterday I had add to some new disks to an SSA110. (host system is an Ultra
Things did not go as expected. The procedure was done with systems live -
taking the relevant mirrors offline, spinning down a drive tray, then adding
After completing this task, ssaadm display c1 reports the new disk location
with "OPEN FAILED". Taking this at face value, that is, something did not
work, we spent a long time investigating. Another disk, another slot,
another tray, etc, all to no avail.
We avoided trying a reconfigure boot as the whole point of systems like this
is to be able to do such tasks without down time.
Finally in frustration we did a drvconfig then a disks (equivalent to a
reconfigure boot). The disk appears and is fine. Problem solved. Or is it?
The questions are:
(a) Have I missed something about adding disks to the SSA that obviates the
need to do a drvconfig and a disks?
It would seem that adding the disks ought be rather more automagical than I
have actually found it to be. If not, and it is required to manually invoke
a rebuild of the /devices and /dev/dsk & rdsk structures, then:
(b) Is it risky to do drvconfig + disks on live boxes that are in production
(there are two connected to these arrays)?
Does drvconfig leave existing /devices entries alone if they are already
consistent with the devices it finds?
Is there any possibility that controller and device numberings will get
changed (ie disaster)?
It all seems rather risky on a live box, yet if it is the only way, where
does that leave the "features" presumably designed so that the system can
stay in production in these situations?
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:14:05 CDT