[Orca-users] Sun Sparc - Replaced disk and Orca fails

[Cockcroft, Adrian]

This is a pretty regular FAQ. The orcallator code makes an array that
isn't always big enough and doesn't resize it.

I posted a suggested fix for the code a few weeks ago.

 

When Solaris reboots it can rebuild the drive and path to inst stuff.
Sometimes just running # drvconfig; disks; tapes

Will clean it up the same way.

 

The workaround is to start orcollator with se -DMAX_DISK=<some large
number> ....

And increase the large number until it works.

 

You can also put the MAX_DISK entry in  /opt/RICHPse/etc/se-defines and
it will apply to all SE commands.

 

Adrian

 

 

  _____  

From: orca-users-bounces+acockcroft=ebay.com at orcaware.com
[mailto:orca-users-bounces+acockcroft=ebay.com at orcaware.com] On Behalf
Of David Devault
Sent: Wednesday, August 10, 2005 11:02 AM
To: orca-users at orcaware.com
Subject: [Orca-users] Sun Sparc - Replaced disk and Orca fails

 

Hello.

 

We have orca running on many systems with no problems, until yesterday.
I had a disk fail in a 280R (internal fiber channel drive0, w/ solaris
8).  This disk has been replaced and the system is fine, however, orca
died when the disk failed and after the replacement orca will not run.
I think this is more of a SE toolkit / Solaris problem than an orca
problem.

 

I get this error from nohup.out:

 

Fatal: subscript: 34 out of range for: GLOBAL_disk_info[34]

 

I suppose this has something to do with the device names and path
instances.  When we reboot this problem goes away and orca works fine.
I'd like to fix this without rebooting.

 

I've traced this back to the path_to_inst file where the old disk is
still configured.  That's not very odd to me because I have seen systems
with three or four old disks still in the path_to_inst, one big
difference is orca was not on the other systems.  I've ran the devfsadm
command and the system seems fine.  Disk Suite mirrored the new disk and
the system is humming along.  Another item to note is that the format
output only contains two internal disks, this is the expected output.  I
was thinking that if orca had a problem with detecting the disks then
format might show the old failed disk as well.  This is not the case.
The system looks fine other than the old failed disk instance showing up
in the path_to_inst I can't see a reference to the old disk anywhere
else.  There must be a scsi cache that the kernel uses with the old disk
device path still in there or something.  Anyone have any suggestions?  

 

Thanks, 
David

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/orca-users/attachments/20050810/1c3c7d52/attachment.html>