unable to mount shadow disk in to shadow set

[Emilton Cortes Jr]

Hello,

Did an upgrade last night from 7.2-2 to 7.3-2. When booting back up received a message about "inconsistent number of blocks". Mounted the primary disks in manually which worked, but still gave me that message.

System came up fine, but when I try to mount in the shadow members I receive this message

MOUNT/SYS DSA1:/SHAD=DRA6: SSHLIV
%MOUNT-I-MOUNTED, SSHLIV mounted on _DSA1:
%MOUNT-I-SHDWMEMFAIL, _$1$DRA6: (SSH) failed as a member of the shadow set
-MOUNT-F-DETSHADINCON, mount has detected an inconsistent state for shadowing
%MOUNT-I-ISAMBR, _$1$DRA5: (SSH) is a member of the shadow set


These are all DRA drives, funny thing is when I mounted in any of the DRA drives I received an inconsistent block message. But the DKC drives mounted in normally with no problems. Could this be a problem with the Raid Card or SWXCR? Anyone else ever encounter this? Thanks in advance.

Emilton

[Mohamed K Ahmed]

Did you changed or added any cardds to the system?
You have mounted DSA1 on DRA6 with label SSHLIV.....but they say they have a label SSH.
You have SWXCRs, have you made sure that 7.3-2 SWXCRs?

So much to think about

Mohamed

[Emilton Cortes Jr]

thanks for the response. I didn't notice the label part. SSHLIV is the correct volume label. I ran this:

SSH$ INIT DRA6: SSHLIV
SSH$ MOUNT/SYS DSA1: /SHAD=DRA6: SSHLIV
%MOUNT-I-MOUNTED, SSHLIV mounted on _DSA1:
%MOUNT-I-SHDWMEMFAIL, _$1$DRA6: (SSH) failed as a member of the shadow set
-MOUNT-F-DETSHADINCON, mount has detected an inconsistent state for shadowing
%MOUNT-I-ISAMBR, _$1$DRA5: (SSH) is a member of the shadow set
SSH$ SH DEV D

[Mohamed K Ahmed]

What is DRA5 doing in there?
Is it mounted already with the name DSA1?
can you post a show dev d

MO

[Emilton Cortes Jr]

DRA5 is the primary Live File Disk, DRA6 shadows this disk.

I was just able to mount in the System shadow with no problem and it is currently copying.SSH$ SH DEV D

Device Device Error Volume Free Trans Mnt
Name Status Count Label Blocks Count Cnt
DSA0: Mounted 0 OVMS-SYS 9849564 377 1
DSA1: Mounted 0 SSHLIV 3489750 36 1
$1$DKA500: (SSH) Online wrtlck 0
$1$DKC0: (SSH) Mounted 0 JOURNAL 7162713 30 1
$1$DKC200: (SSH) Mounted 0 TEST 4505193 2 1
$1$DRA0: (SSH) ShadowSetMember 0 (member of DSA0:)
$1$DRA1: (SSH) ShadowCopying 0 (copy trgt DSA0: 46% copied)
$1$DRA2: (SSH) Mounted 0 SSHALT 3566286 3 1
$1$DRA3: (SSH) Mounted 0 SSHALT2 3503250 2 1
$1$DRA4: (SSH) Mounted 0 SSHOPT 7735806 1 1
$1$DRA5: (SSH) ShadowSetMember 0 (member of DSA1:)
$1$DRA6: (SSH) Online 0
$1$DRMA0: (SSH) Online 0
$1$DVA0: (SSH) Online 0
SSH$

[Mohamed K Ahmed]

Try This

init $1$DRA6: SSHLIV
mount/sys DSA1: /shado=($1$DRA5:, $1$DRA6:) SSHLIV

It should mount fine, unless...do you know for sure that DRA5 and DRA6 are identical drives with the same number of cylinders and sectors and size..

post a show dev DRA5/full and show dev DRA6/full
OpenVMS has to see totally IDENTICAL drives for shadowing, though new versions of the shadowing software fixed this

Mohamed

[Emilton Cortes Jr]

SSH$ INIT DRA6: SSHLIV
SSH$ mount/sys DSA1: /shado=($1$DRA5:, $1$DRA6:) SSHLIV
%MOUNT-I-MOUNTED, SSHLIV mounted on _DSA1:
%MOUNT-I-ISAMBR, _$1$DRA5: (SSH) is a member of the shadow set
%MOUNT-I-SHDWMEMFAIL, _$1$DRA6: (SSH) failed as a member of the shadow set
-MOUNT-F-DETSHADINCON, mount has detected an inconsistent state for shadowing
SSH$




SSH$ SH DEV/FULL DRA5:

Disk DSA1:, device type SWXCR, is online, mounted, file-oriented device,
shareable, available to cluster, error logging is enabled, device supports
bitmaps (no bitmaps active).

Error count 0 Operations completed 146502
Owner process "" Owner UIC [SYSTEM]
Owner process ID 00000000 Dev Prot S:RWPL,O:RWPL,G:R,W
Reference count 29 Default buffer size 512
Total blocks 8378368 Sectors per track 64
Total cylinders 8182 Tracks per cylinder 16
Logical Volume Size 8380080 Expansion Size Limit 8589312

Volume label "SSHLIV" Relative volume number 0
Cluster size 9 Transaction count 36
Free blocks 3489750 Maximum files allowed 419004
Extend quantity 5 Mount count 1
Mount status System Cache name "_DSA0:XQPCACHE"
Extent cache size 64 Maximum blocks in extent cache 348975
File ID cache size 64 Blocks in extent cache 26244
Quota cache size 0 Maximum buffers in FCP cache 790
Volume owner UIC [SYSTEM] Vol Prot S:RWCD,O:RWCD,G:RWCD,W:RWCD

Volume Status: ODS-2, subject to mount verification, write-back caching
enabled.

Disk $1$DRA5:, device type 1 Member JBOD, is online, member of shadow set DSA1:,
error logging is enabled.

Error count 0 Shadow member operation count 121838
Allocation class 1

SSH$ SH DEV/FULL DRA6:

Disk $1$DRA6: (SSH), device type 1 Member JBOD, is online, file-oriented device,
shareable, available to cluster, error logging is enabled.

Error count 0 Operations completed 532
Owner process "" Owner UIC [SYSTEM]
Owner process ID 00000000 Dev Prot S:RWPL,O:RWPL,G:R,W
Reference count 0 Default buffer size 512
Total blocks 8378368 Sectors per track 64
Total cylinders 8182 Tracks per cylinder 16
Allocation class 1

SSH$

[Mohamed K Ahmed]

ok, Are you using the latest version of shadowing?.
Looking on records, the error you are having means:

DETSHADINCON, mount has detected an inconsistent state for shadowing

Facility: MOUNT, Mount Utility
Explanation: MOUNT has detected an internal inconsistency while attempting to mount a shadow set. This message indicates a failure in either MOUNT or the OpenVMS Volume Shadowing software.
User Action: Contact a Compaq support representative and provide as much detail as possible about the circumstances surrounding this error.

HTH

Mohamed

[Emilton Cortes Jr]

Thanks for all your responses Mohamed, not really sure what version I am using, but the weird thing is that the DSA0 shadow set mounted in fine although I did receive a message about inconsistency in the beginning. Not sure how to check the version of shadowing.

[Mohamed K Ahmed]

are there any shadowing patches for 7.3-2, is the SWXCR versions compatible with 7.3-2
I have 7.3-1 on an AS2100 with swxcr version 2.7 and it is working fine

[Martin P.J. Zinser]

Hello,

no specific shadowing patches for 7.3-2 are out yet.

What does an anal/disk/shadow give?

Greetings, Martin

[David B Sneddon]

Try using /CONFIRM on the mount command.

[David B Sneddon]

Another thought... try initializing DRA6 with a different name e.g. DUMMY then adding it in with /CONFIRM.

[Wim Van den Wyngaert]

Just saw in your message :
Logical Volume Size 8380080 Expansion Size Limit 8589312

The first disk is 8380080 in size but can increase to 8589312.

The second disk is 8378368 in size, thus smaller than the size of the first disk but can not be expanded to the limit size of 8589312.

Check init/lim.

I may be wrong because I'm stuck on 7.3.

[Ian Miller.]

The logical sizes of the two volumes have to be the same. You can re-init the target disk to change this.

[Uwe Zessin]

Ha! You have good eyes, Wim!

It is strange that DSA1: with member DRA5: shows:
...
> Total blocks @8378368@ Sectors per track 64
> Total cylinders 8182 Tracks per cylinder 16
> Logical Volume Size @8380080@ Expansion Size Limit 8589312
...

And DRA6: shows:
> Total blocks @8378368@ Sectors per track 64
> Total cylinders 8182 Tracks per cylinder 16

OpenVMS V7.3-2 allows a volume to grow later, provided that the bitmap is large enough. And it allows shadowing of disks with different physical size - I have tried it with a field-test version.

I don't have experience with the volume growth feature, but it looks like both disks have physically the same size, but somehow the 'Logical Volume Size' is bigger than the physical. Honestly, I do not know if it is OK that it displays a bigger value. I can understand if it is smaller, but bigger?

You can try if '$ ANALYZE/DISK_STRUCTURE/REPAIR DSA1:' fixes it.

[Mike Naime]

I thought that 7.3-2 was supposed to allow you to shadow different size disks. At least that was one of the "improvements" that I remember from the release notes.

[David B Sneddon]

V7.3-2 DOES support disks of different sizes. I recently upgraded one machine and when it came time to rebuild the system disk shadow set , the second member was dead. The original disk is a 4GB disk and I added a 9GB disk and it is running quite happily.

[Jan van den Ende]

As this all looks to me, Wim had it all, except for the final conclusion:
DSA6 has a LOWER expansion limit than DSA1/DRA5.
Like David reported, since 7.3-2 you CAN shadow unequal-sized devices, BUT: the device to be added CANNOT be SMALLER than the one(s) already in the set!!
Do an INITIALIZE of DRA6 with /LIMIT=8589312 (or bigger), and my guess is that you then WILL be able to add DRA6 to DSA1.

hth

Jan

[Uwe Zessin]

Excuse me for my insistence, but it looks to me like both disks have the same physical size (8378368 blocks), but VMS somehow beleives that the current shadowset (member) has a bigger logical size (8380080 blocks).

Please anybody re-read my previous message and tell me if there is an error in my thinking and where it is.

[David B Sneddon]

Uwe, your observation is correct. I just checked a lot of shadow sets and in all cases the total blocks was equal to the logical volume size. It would be interesting to try to dump the blocks between the total size and the logical volume size...

[Malcolm Wade]

Interesting.

We have a similar problem right now which HP are looking at.

Scenario was a little different though, in a shadowed environment one 9GB DRA unit failed (it was a JBOD - doh!). I replaced the drive and rebuilt the JBOB but shadow says it's too big! Doesn't matter what I do, the 9GB drive (JOBOD or Raid-1) always rebuilds as 17772544 block drive, yet the original DRA drive, when in a shadow set was 17768198. VMS, at boot time reports the volumes to be 17772544 blocks.

The similarities are that this cluster was originally V7.2-1 (when the shadows were built and not touched at the SWXCR level since), then upgraded to V7.3-1 with no problems.

The system disks, both Raid-1 but not DSA devices are 17772544 blocks.

I reckon the V7.2-x shadow driver or something from that OS version timeframe has pilfered some blocks somewhere.

Unless HP come up with a fix I am going to be re-initing all the smaller block drives over the weekend and re-loading data! I gotta get this x-site shadow disk back on-line.

[Lawrence Czlapinski]

You might try repreparing the RAID drive as a data drive by typing:
$@SYS$MANAGER:DR$INIT DRxx:
This reserves blocks for shadowing.
Then try the mount command again.
We use format:
$mount/system/noassist dsax: /shad=
("$1$dray:") SSHLIV SSHLIV (or mount/cluster)