All...
Here is a weird problem - Dunix v4.0d as8400 5 cpu's.
1 x ESA10000 cabinet. Each zone has a pair of dual redundant hsz70's It
WAS populated with 9gb disks (the exact configuration was not important) and
all was working ok.
I have replaced the 9's with 18's. The top zone is configured (stripe sets
etc) as an identical copy of the lower zone. The LSM volumes will be
mirrored between the two zones.
Now...
I have had no problems with the top 3 (of 4) shelves in each zone. The
stripe sets (2 x 3 disk stripe sets per shelf) are created, the units are
created, the device special files are created, the disk labels are written,
the disks are added to LSM and the volumes are created and mirror sets set
up.
The only issue was that voldiskadd took a long time (say 3-4 minutes but I
didn't time it exactly) to add the disks to the disk group. I put this down
to the system being very busy (load average around 5-7 all the time).
However...
The bottom shelf in each zone is causing me problems. The disks initialised
(but took say 30 seconds each to complete) ok (it was odd that the
initialisation did not respond immediately as has been the case in the
past). 2 stripe sets created ok. The 2 stripe sets were initialised ok and
units added ok.
I did a 'scu scan edt bus 17' followed by a 'scu show edt bus 17 | wc -l'.
The 'scu show...' showed 2 more than the same command before the 'scu
scan...' - all just as expected.
I created the device special files ok. A 'disklabel -z' followed by a
'disklabel -wr rz??? HSZ70' created the disk label. A 'disklabel -r rz???'
showed the c partition with the correct number of sectors.
Now, the voldiskadd takes say 5 minutes then fails with the following
message:
Initialization of disk device rzb136 failed.
Error: voldisk: Device rzb136: define failed:
Disk write failure
I originally put this down to some problem with one of the disks. However
this seems not to be the case. I got the same problem with the 2nd stripe
set (top zone bottom shelf).
I then got exactly the same problem with BOTH stripe sets in the lower zone.
This is weird as the lower zone is connected to its own pair of HSZ's.
So...
I deleted the device special files for the (4) offending disks. Did a 'scu
scan edt bus 17' & '...bus 18' to blow away any references to these devices.
Deleted the units, stripe sets and disks in question from the two zones.
Then...did the whole thing again... with exactly the same problem.
I did a 'newfs' of the a partition (131072) blocks. This does complete but
is very slow (say 2 minutes. It does not respond with the usual zippy speed
you expect. Same for the 'b' partition of 262144 blocks.
I repeated the undo procedure again documented above after restarting both
of the redundant pair of HSZ's. Same problem.
I can write to these disks but it seems VERY slow. Any ideas what to do
next? Has anybody seen this before?
Thanks - Tony
PS... By the way, if I dont know what jumbo patch (1, 2, 3 etc) has been
installed, whats the easy way to find out?
+-----------------------------------------------------------------+
| TONY MILLER - Systems Projects - VODAFONE LTD, Derby House, |
| Newbury Business Park, Newbury, Berkshire. |
+-------------+---------------------------------------------------+
| Phone | 01635-507687(local) |
| Work email | ANTHONY.MILLER_at_VF.VODAFONE.CO.UK |
| X.400 | G=ANTHONY; S=MILLER; C=GB; A=GOLD 400; P=VODAFONE |
| FAX | 01635-583856 |
+-------------+---------------------------------------------------+
Quotation: "Is the glass half full or half empty?? ...
Well, drink it anyhow, that's what I say".
Pete Goss.
Disclaimer: Opinions expressed in this mail are my own and do not
reflect the company view unless explicitly stated. The information
is provided on an 'as is' basis and no responsibility is accepted for
any system damage howsoever caused.
Received on Wed May 19 1999 - 08:18:00 NZST