Shadowset mount receives "MOUNT-F-WRONGVU"
rc...@adams.com
There are approximately 10 shadowsets. When I issue the standard command
mount/sys/clu dsa4:/shad=$1$dua220: path4 path4
I now receive a message:
%MOUNT-W-RMTMNTFAIL, _DSA4: failed to mount on node HNAB
-MOUNT-F-WRONGVU, device is already a member of another virtual unit
But the shadowset mounts on the other node anyway. I get this message
anytime I mount a secondary or tertiary member into a shadowset, on either
node, but every time I get the message, and everytime the mount succeeds
regardless on both nodes (seen by mnt cnt on a show device dsa).
I search the patch db and could not find a patch related to my symptoms.
Has anyone seen this before?
Thanks
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
Hans Bachner
<snip>
> mount/sys/clu dsa4:/shad=$1$dua220: path4 path4
>
>I now receive a message:
>
>%MOUNT-W-RMTMNTFAIL, _DSA4: failed to mount on node HNAB
>-MOUNT-F-WRONGVU, device is already a member of another virtual unit
>
>But the shadowset mounts on the other node anyway. I get this message
>anytime I mount a secondary or tertiary member into a shadowset, on either
>node, but every time I get the message, and everytime the mount succeeds
>regardless on both nodes (seen by mnt cnt on a show device dsa).
The mount count of the DSA device does not reflect the number of
shadow members mounted.
Does $ SHOW DEVICE DSA4 show all shadow members that should be there?
Did you move disks from one shadow set to another? The disk stores
shadowset information, so you need to re-init it before adding it to a
different shadow set or use /OVERRIDE=SHADOW.
Is HNAB the local (where the mount command is issued) or a remote
node?
---------------- just my personal thoughts ----------------
Hans Bachner
Compaq Computer Austria
Compaq Services - Software Support
Office E-Mail: bac...@lnzali.enet.dec.com or Hans.B...@compaq.com
Private E-Mail: Hans.B...@altavista.net
rc...@adams.com
Hans.B...@merlin.at wrote:
> rc...@adams.com wrote on Wed, 04 Nov 1998 15:20:23 GMT:
>
> <snip>
> > mount/sys/clu dsa4:/shad=$1$dua220: path4 path4
> >
> >I now receive a message:
> >
> >%MOUNT-W-RMTMNTFAIL, _DSA4: failed to mount on node HNAB
> >-MOUNT-F-WRONGVU, device is already a member of another virtual unit
> >
> >But the shadowset mounts on the other node anyway. I get this message
> >anytime I mount a secondary or tertiary member into a shadowset, on either
> >node, but every time I get the message, and everytime the mount succeeds
> >regardless on both nodes (seen by mnt cnt on a show device dsa).
>
> The mount count of the DSA device does not reflect the number of
> shadow members mounted.
>
> Does $ SHOW DEVICE DSA4 show all shadow members that should be there?
>
> Did you move disks from one shadow set to another? The disk stores
> shadowset information, so you need to re-init it before adding it to a
> different shadow set or use /OVERRIDE=SHADOW.
>
> Is HNAB the local (where the mount command is issued) or a remote
> node?
>
Hans,
Thank you for your post. Yes I am aware that mnt cnt indicates cluster
members that have the device mounted - that is why I was checking its value
after the message appeared. I have been able to successfully recreate this
several times, EVEN after re-initing the drive and then issuing the mount
command. Last night I had a stable two member DSA4 shadowset, mounted
clusterwide. When I attempted to add a third member in, I received the same
message - hinting that the other node (HNAB) had not mounted the shadowset.
I have been able to get this peculiarity to work both directions - while
logged on HNAA and while logged on HNAB. I have several years of experience
with shadowsets, and over 40 difference VMS installation Client sites, and
have never seent his behavior before. That is why I am wondering if there is
a patch that fits this description. Yes, there is the error message, but
when I issue the sh device dsa4 command, all three members are there - with a
mnt cnt of 2.
Thanks again,
Rob
Dave Pickles
>
> I have just migrated an application to a new VMS7.1 AS4100 two node cluster.
> There are approximately 10 shadowsets. When I issue the standard command
>
>
> I now receive a message:
>
> %MOUNT-W-RMTMNTFAIL, _DSA4: failed to mount on node HNAB
> -MOUNT-F-WRONGVU, device is already a member of another virtual unit
>
> But the shadowset mounts on the other node anyway. I get this message
> anytime I mount a secondary or tertiary member into a shadowset, on either
> node, but every time I get the message, and everytime the mount succeeds
> regardless on both nodes (seen by mnt cnt on a show device dsa).
>
>
> Has anyone seen this before?
>
> Thanks
Yes I did see this once when manually creating a new shadow set. I was in a
hurry to get some out-of-hours maintenance work done, and I can't remember how
I cleared the problem - probably rebooted one or both nodes.
There have been quite a few patches for MOUNT, SHADOW and CLUSTER on VMS 7.1.
We generally keep up-to-date with the class 1 and 2 patches, and the fact that
I haven't seen the effect since suggests that it has been fixed by one of
them.
--
Dave Pickles
Hans Bachner
If the existing shadow set and the to-be-added disk have their index
files (and home blocks) in different positions (e.g. because the
/INDEX=xxx qualifier has been used with the INITIALIZE command), and a
mount command is executed on another cluster member very shortly after
the first mount command (which initiates the shadow copy), MOUNT
becomes confused and returns the message mentioned in the base
posting.
To solve this problem, initialize the new disk with the same attibutes
as the existing shadow set. You can check the index file position with
$ DUMP /HEADER /BLOCK=COUNT=0 disk:[000000]INDEXF.SYS - just look at
the extent allocation information.
Another possible way is to mount the original shadowset on only one
cluster node, add the new member and let the shadow copy finish (or at
least progress far enough) before mounting the shadow set clusterwide.
I'm not quite sure but there is a possibility that the latest
ALPMOUN0n_nnn and VAXMOUN0n_nnn ECOs fix the problem as well.
Hope this helps,
Hans.
rc...@adams.com
Through experimentation I have found this behavior exists in the case the
shadowset has been previously inited, not only with specific /INDEX=, but
also, /CLUSTER=, and /HEAD= as well. When adding the third member in, if I
did not init it with the identical /INDEX=end/CLUSTER=20/HEAD=40000 then I
would receive the message. All three were necessary.
Hm. I will install all the ALPMOUN* patches and see if this disappears.
-----------== Posted via Deja News, The Discussion Network ==----------
Andy Goldstein
]
] Interesting,
This is a known problem in MOUNT. Unfortunately, as far as I can make
out from the edit history, it has not yet been fixed. The correct
solution is pretty complicated. You can work around it as described -
init the member to be added to the set with parameters that are
consistent with the existing members of the shadow set.
The cause of the problem is that the shadowing metadata is in the file
structure - specifically the storage control block. All the INIT
parameters cited affect where the storage control block is located.
MOUNT locates the storage control block by working through the file
structure. Once located, however, the shadow driver references it by
LBN. Further, it assumes that the storage control block will be on the
same LBN on all shadow set members. (Which is indeed true once the set
is consistent.)
So if you add a new member whose current storage control block is in a
location other than that of the existing shadow set,
(1) MOUNT identifies the member as a copy target
(2) The shadow driver initiates the shadow copy, writing an appropriate
storage control block on the new member at the LBN where it belongs in
the shadow set. Because the old storage control block of the member was
at a different LBN, it is not overwritten.
If you now mount this shadow set on another node in the cluster before
the shadow copy has started, MOUNT will read the old home block, etc.,
and locate the old storage control block through the file structure.
Because we're mounting a shadow set that's mounted elsewhere in the
cluster, MOUNT expects the storage control blocks to be consistent, and
they're not.