I got lots of help, thanks!
From: rem_at_MATH.AMS.ORG
From: "Dave Golden" <golden_at_falcon.invincible.com>
From: gmarinos_at_violet.berkeley.edu (George Marinos)
From: Tom Webster <webster_at_i5142311.mdc.com>
From: "Michael A. Crowley" <mcrowley_at_mhc.mtholyoke.edu>
From: John Hascall <john_at_iastate.edu>
From: Eric <Eric.Rostetter_at_utoledo.edu>
From: "Edward C. Bailey" <ed_at_pigdog.niehs.nih.gov>
From: Gyula Szokoly <szgyula_at_skysrv.Pha.Jhu.EDU>
From: berrigan_at_kent.wednet.edu (Bob Berrigan)
From: KPOOTS_at_mickey.gects.ge.com
From: Gary Menna <G.Menna_at_isu.usyd.edu.au>
From: Pete Gronbech <p.gronbech1_at_physics.oxford.ac.uk>
From: rlangrid_at_progress.co.uk (Roy Langridge)
From: "Mitch Bertone" <mbertone_at_gtech.com>
My problem statement:
>>I have just configured in a 4 disk (4 gig each, Digital rz29's) array,
>>on a 3 channel pci controller (KZPSC-BA) on a 2100 4/275. I spread the
>>disks across channels, 2 disks on one channel, and one each on the other
>>two channels.
>>
>>The configuration was easy and by the book. I got done thursday,
>>aug 15 at noon, and left it initializing the array (the last step
>>in the configuration process). Now, more than 24 hours later, it
>>is still only 93% done!
Here's the two answers that pointed me in the right direction:
------------------------------------------------------------------------
The SRLMGR (on the same disk/CD) as the SWXCRMGR software isn't
as pretty, but my FSE claims it can be twice as fast as the
SWXCRMGR.
------------------------------------------------------------------------
Are you using a serial terminal as opposed to a graphics display? - in which
case the answer is to use srlmgr instead of swxcrmgr - Its easily
recognisable on the standalone disk by it lack of documentation in the
manuals :-)
- I was told it's something to do with screen refesh rates ..
------------------------------------------------------------------------
srlmgr indeed was the answer. There was actually nothing wrong
in the first place, other than swxcrmgr spent around 30 hours updating
the screen to tell me about its progress, and only an hour or
so doing the initialization!
srlmgr seemed more or less functionally identical to swxcrmgr, but
was able to do the intialization in less than an hour. Remember,
unless you have a VGA (I think that's the right buzz word) monitor,
srlmgr is the only way to go... here, I'll write it in
uppercase... SRLMGR <--------- :-)
Here's some other stuff other people said that seems worth passing
on, but which didn't relate to my problem:
-------------------------------------------------------------------------
Note there a "widely known" (bull!) problem with mixing
internal and external storageworks boxes with this controller.
We had:
1000a [7 drives in this cabinet]
+ba356 [7 drives]
+ba356 [7 drives]
and that was flakey as can be, while what we have now:
1000a
+ba356 [7 drives]
+ba356 [7 drives]
+ba356 [7 drives]
is rock solid.
------------------------------------------------------------------------
Try setting write back cache on before you initialize, this will speed
things up.If you create several logical drives from this disk group
then try initializing them one at a time.
------------------------------------------------------------------------
If any one has read this far: I've had it set for write back cache
the whole time. I think I have all that is required to support
write back cache: KZPSC-BA, battery backup, the 2100 has built in
storageworks boxes (ba35X?). When I boot OSF on it, the following
comes out when the system is probing the devices:
re0 at xcr0 unit 0 (unit status = CRITICAL, raid level = 5)
(WRITE BACK cache operation NOT SUPPORTED
So far we've checked to make sure the battery card is there, it is.
There's a switch on the card which sets it either for internal or
external battery, we've tried it both ways. Why is write back not
supported?
-Mike
Received on Tue Aug 20 1996 - 17:07:41 NZST