On the ES40 I create a shadowset consisting of two
members, each on a different HSG80 raid controller.
The HSG80s are running 8.8-4F.
Everything works fine.
If I dismount this shadowset from the ES40 and mount
it on the rx2600 it works fine there also.
If I leave it mounted on the ES40 and also mount it
on the rx2600 it doesn't work properly. It takes a
long time ( approx 5 minutes ) to mount the shadowset
on the rx2600, during which time the shadowset goes in
and out of mount verification numerous times on the
ES40. Once mounted any I/O operations on the shadowset
will periodically hang for 30 seconds or so.
There are no errors logged on any of the devices.
The problem doesn't happen all the time and doesn't
always happen on the same disks.
Anyone else seen anything like this? What should I be
looking at to troubleshoot it?
> Anyone else seen anything like this? What should I be
> looking at to troubleshoot it?
If you have a support contract, please contact your support centre; this
may wind up being quite involved -- we may want forced crashes, etc ...
If you don't have a contract, email me directly, and I'll see what I can
do.
Are you familiar with DKDRIVER logging within SDA? We'll probably need to take
a look at what DKDRIVER thinks is happening on the rx2600. I'm also curious
as to what the shadowing driver thinks is happening, but we'll start with
DKDRIVER and work our way up the driver stack . . .
You may have mentioned this (if so, I apologize for missing it), but what
happens if the shadow set is *only* mounted on the rx2600?
For DKDRIVER logging on the rx2600, this is what you'll need to do . . .
$ ANAL/SYS
SDA> DKLOG START $1$DGAnnnn: /ENTRIES = 1024 ! do this for each member of the
shadow sets that are problematic
SDA> EXIT
$ ! mount the relevant shadowsets
$ ! once the shadowsets start going in and out of mount verification . . .
$ ANAL/SYS
SDA> SET OUT DGAnnnn.out
SDA> DKLOG SHOW $1$DGAnnnn:
Do those above steps for each device on which you've started logging above.
I'm not claiming that I'll be able to diagnose the problem with just this info,
but it'll be a good start.
--
Rob Brooks VMS Engineering -- I/O Exec Group brooks!cuebid.zko.hp.com