mount-f-xsmbrs message during mount of shadow set

[Oswald Knoppers_1]

Hello,

I get this message during while mounting some disks. This disk is already mounted on the other nodes in the cluster. The exact mount command is:

$ mount/cluster dsa210/shad=($1$dga1010:,$1$dga1110:) disk10

If i change /cluster to /system i do not see the error. I only get this message on two of our disks and i fail to see the difference between these disks.

Anybody ever seen this?

Thanks,

Oswald

[Karl Rohwedder]

XSMBRS means, you tried to mount more than 3 members in a shadowset.
This is strange, because:
- your command only contains 2 members
- if dsa210 is mounted on other clustermembers with other disks, you should not be able to mount it /SYSTEM

Have you checked on other nodes, that ds210 consists exactly of the disks 1010 and 1110?

regards Kalle

[Oswald Knoppers_1]

Hi Kalle,

Yes the shadow set has two members. Exactly the same members on all nodes (1010 and 1110 in this case). I only get this message on two of our 10 shadow sets.

The mount command does work however, access to these two disks works fine on all nodes.

Oswald

[Volker Halle]

Oswald,

do you have more than one system disk in the cluster ? If so, different VMS versions or patch levels ?

Would a

SYSMAN> SET ENV/CLUS
SYSMAN> DO MOUNT/SYSTEM DSA210:/SHAD=($1$DGA1010:,$1$DGA1110:) DISK10

result in an error on any of the systems ?

In general, once a shadowset is mounted on at least one node in the cluster, you could use a simple MOUNT/SYS DSAx: label on the other nodes and don't have to specify the members.

Volker.

[Oswald Knoppers_1]

Hi Volker,

This is a 5 node cluster, each system has its own system disk. VMS versions are the same, there might be slight differences in patch level...

I do not have a test disk to experiment with and unmounting dsa210 on all nodes is unfortunally not an option.

I know that a mount/sys is sufficient. Also there doesn't seem to be a problem. I just do not understand why while mounting two of my disks i get this message (and only with the /cluster qualifier). Mounting the other disks with exactly the same command doesn't give me this message.

One other thing (probably relevant) is that in the last couple of months we have phased out tho HSG80's and replaced them with EVA storage. This means that we now have other DGA units for each shadow member. Maybe somewere in VMS the old unit numbers are still lingering?? On the other hand this change happened on all my disks and not only to the two giving this error.

Thanks,

Oswald

[Robert Brooks_1]

I cannot explain your observations.

However, a "quick" way to mount a shadow set that is mounted elsewhere on the cluster is to simply omit the members from the command line!

For your situation, the command would be

mount/cluster dsa210 disk10



-- Rob

[VMS Support]

What version of OpenVMS are you running ?
We run V7.2-1H1 and V7.3 and I get the odd funny when adding members into shadow sets.

I get something like the following error.

Remove member from shadow set.
Use SYSMAN to check status of shadow set on all nodes (Show dev dsa) and status of removed disk (Show dev dga).
Add member back into shadow set with a /cluster/system/shadow=dgaxxx
and sometimes I get an error saying
unit is already a member of an existing shadow set. The mount completes anyway and the disk is added to the shadow set. This happens about once in every four mounts.
I put it down to a VMS bug that will with luck has been fixed in V7.3-2.
First time I saw it I had a bit of a panic ...checked HSG access paths to disk. Ensure that only this cluster has access to disk etc ...All was ok.
Disk was added to shadow set anyway.

[Volker Halle]

re: VMS Support


Add member back into shadow set with a /cluster/system/shadow=dgaxxx
and sometimes I get an error saying


A simple MOUNT/SYSTEM DSAx:/SHAD=dgaxxx command is enough to add a member to an existing shadowset. This does not need to be done cluster-wide with /CLUSTER. A shadowset is a cluster-wide resource and does have the same common attributes on all cluster members.

Volker.

[John Gillings]

Oswald,
Dumb question...

What does

$ SHOW DEVICE DSA210 say?

If DSA210 already exists on any node and already has 2 members then attempting to add two more members should generate MOUNT-F-XSMBRS.

Maybe you should preceed the MOUNT with a DISMOUNT/CLUSTER DSA210?

[Oswald Knoppers_1]

re Several,

Thanks for all the suggestions.

We run VMS 7.3-2 on this cluster. Patch levels are not exactly the same, 3 (ES40) have vms732_fibre_scsi V4.0, the other two (ES45/GS160)have V3.0. The three es40's have also vms732_sys V6.0, the other two V5.0. The ES40'have vms732_update v3.0 the other two V2.0. All have vms732_hbmm V2.0

The device looks like:

Device Device Error Volume Free Trans Mnt
Name Status Count Label Blocks Count Cnt
DSA210: Mounted 0 DISK10 65376396 222 5
$1$DGA1010: (ITIV60) ShadowSetMember 0 (member of DSA210:)
$1$DGA1110: (ITIV60) ShadowSetMember 0 (member of DSA210:)

This shows exactly the same on all nodes.

Re Robert

This gives me the same message:

$ sho dev disk10

Device Device Error Volume Free Trans Mnt
Name Status Count Label Blocks Count Cnt
DSA210: Mounted 0 DISK10 65376396 1 5
$1$DGA1010: (ITIV47) ShadowSetMember 0 (member of DSA210:)
$1$DGA1110: (ITIV47) ShadowSetMember 0 (member of DSA210:)
$ dism disk10
$ mount/clus disk10 disk10
%MOUNT-I-MOUNTED, DISK10 mounted on _DSA210:
%MOUNT-I-ISAMBR, _$1$DGA1010: (ITIV47) is a member of the shadow set
%MOUNT-I-ISAMBR, _$1$DGA1110: (ITIV47) is a member of the shadow set
%MOUNT-W-RMTMNTFAIL, _DSA210: failed to mount on node ITIV60
-MOUNT-F-XSMBRS, maximum number of shadow members exceeded
%MOUNT-W-RMTMNTFAIL, _DSA210: failed to mount on node ITIV46
-MOUNT-F-XSMBRS, maximum number of shadow members exceeded
%MOUNT-W-RMTMNTFAIL, _DSA210: failed to mount on node ITIV48
-MOUNT-F-XSMBRS, maximum number of shadow members exceeded
%MOUNT-W-RMTMNTFAIL, _DSA210: failed to mount on node ITIV70
-MOUNT-F-XSMBRS, maximum number of shadow members exceeded
$ sho dev disk10

Device Device Error Volume Free Trans Mnt
Name Status Count Label Blocks Count Cnt
DSA210: Mounted 0 DISK10 65376396 1 5
$1$DGA1010: (ITIV47) ShadowSetMember 0 (member of DSA210:)
$1$DGA1110: (ITIV47) ShadowSetMember 0 (member of DSA210:)
$

Regards,

Oswald

[Camiel]

Oswald,

couldn't it simply be that because these two disks are already (or still - you did a dismount, not a dismount/cluster) mounted on the other cluster members, an attempt to add these two disks again results in this error message?

Try if this gives you the same error on your node as well the second time:

$ mount/cluster disk10 disk10
$ mount/cluster disk10 disk10

Camiel.

[Oswald Knoppers_1]

Hi Camiel,

Of course this disk is still mounted on the other nodes. I just want this node to mount the disk as well.

The message indicates that i am trying to add more then three members to a shadowset. Which is not supported. But i am not trying to do that (as far as i can tell :-)).

Oswald

[VMS Support]

Oswald,
You say you are running 7.3-2.
Thats a blow. I have also had the max shadow member messages in the past as well. I put it down to 7.2-1H1 and was hoping it would go away when we upgrade to 7.3-2.
It's just something we live with. The member gets added to the shadow set anyway ...regardless of any errors.


Kevin Raven.

[Jan van den Ende]

Oswald,

a wild guess, but

-you are running off of several system disks
-you are using multi-pathed EVA disks

Could it be, that different systems initially (appear to?) use different paths, and regard that as being different (leading to a too high membercount reported) before the software notices the equivalence, and executes the command?
I would also suggest to ASAP update to the level of FIBER_SCSI. The problem might just get resolved by that.

Proost.

Have one on me.

jpe

[Robert Brooks_1]

jpe wrote . . .

a wild guess, but

-you are running off of several system disks
-you are using multi-pathed EVA disks

Could it be, that different systems initially (appear to?) use different paths, and regard that as being different (leading to a too high membercount reported) before the software notices the equivalence, and executes the command?
I would also suggest to ASAP update to the level of FIBER_SCSI. The problem might just get resolved by that.


----

Multipath is irrelevant here; neither MOUNT nor shadowing know and/or care about how many paths a device has. That would be a very
serious layering violation!

-- Rob

[Robert Brooks_1]

Kevin wrote . . .

Oswald,
You say you are running 7.3-2.
Thats a blow. I have also had the max shadow member messages in the past as well. I put it down to 7.2-1H1 and was hoping it would go away when we upgrade to 7.3-2.
It's just something we live with. The member gets added to the shadow set anyway ...regardless of any errors.

--

There is no shadowing (or mount) problem here.

If you get
the XSMBRS message, it is because a mistake was made on the command line.

You don't need to "live" with anything; you need to correctly specify the devices on the command line and understand when the /CLUSTER and /SYSTEM qualifiers are needed.

As I mentioned earlier, the quickest and easiest way to mount a shadowset that already
exists somewhere on the cluster is to simply
omit the members entirely, and to simply specify the device and volume label.


--- Rob

[Jan van den Ende]

Rob,


Multipath is irrelevant here; neither MOUNT nor shadowing know and/or care about how many paths a device has.


This does not necessarily mean we disagree:
My reasoning is, IF the device is seen including the path name, there COULD be combinations that (errenously) APPEAR different, and before that is straightened out, the XSMBRS gets reported...

Oh well, I was just guessing, I can just as likely have mis-guessed..

Proost.

Have one on me.

jpe

[Volker Halle]

Oswald,

so you get the XSMBRS message on a MOUNT/CLUSTER on all nodes except the local node. A MOUNT/SYS specifying the shadow VU and both members does not fail, even if the shadowset is already mounted with the members specified on the command-line (tried on V8.2). I would expect the same to happen with a MOUNT/CLUSTER - and according to your experience - it does behave (correctly) like this on most of your disks. Specifying both members may not be necessary, but IMHO should not be considered a 'command line error'. It works locally, even if the shadowset is already mounted with both members, why shouldn't it also work remotely ?

The XSMBRS error message comes from MOUNT itself (module [MOUNT96]SHADOW_MOUNT). Somehow the 'remote' mount command does not correctly recognize, that the members specified on the command line are already VALID members of the shadowset and not NEW members.

Volker.

[Oswald Knoppers_1]

Rob wrote:

As I mentioned earlier, the quickest and easiest way to mount a shadowset that already
exists somewhere on the cluster is to simply
omit the members entirely, and to simply specify the device and volume label.
--
I came across these errors during startup. During startup it is not known if the shadowset is already mounted somewere else in the cluster, therefore i specify the members and use the /cluster qualifier.

I agree with Volker, the message is wrong. The question is should i be worried...

Thanks for al your replies so far.

Oswald