Re: long, boring explanation of minicopy (and HBVS, in general)

From: Phillip Helbig---remove CLOTHES to reply (helbig_at_astro.multiCLOTHESvax.de)
Date: 05/30/04 

Date: Sun, 30 May 2004 11:34:41 +0000 (UTC)

In article <AqZWoVHs7m63@cuebid.zko.dec.com>,
brooks@cuebid.zko.dec.nospam (Rob Brooks) writes:

> I have been following a bit of these discussions, but not with any great
> detail. Independent of whether or not there has been any comp.os.vms
> consensus about what is the proper behaviour, if you ask a specific
> question about perceived behaviour, I'll tell you what the expected
> behaviour is, assuming a modern version of OpenVMS.
>
> > I'm still confused about VAX support. Which of the following situations
> > would benefit from DISMOUNT/POLICY-MINICOPY (assume two VAX and one
> > ALPHA node in the cluster):
>
> A VAX cannot have a minicopy bitmap on it. A VAX **can** have its
> writes registered on a minicopy bitmap that exists on an Alpha (or Itanium,
> for V8.2 and beyond. The implementation of Host-Based Volume Shadowing on
> Itanium **IS IDENTICAL** to that on the Alpha hardware. The only differences
> in the code exist to deal with the differences in the calling standards of the
> two architectures.)
>
> In all the examples you give, the only one that could not benefit
> from minicopy is the one where the Alpha is shut down. For the others,
> as long as the shadow set is mounted on an Alpha (even if its connection
> is MSCP through a surviving VAX), you can use minicopy. If a shadow
> set is mounted on an Alpha, but its only connection is MSCP through
> the VAX being shut down, then you cannot use minicopy.
>
> If this is not clear, please let me know and I'll take another stab at it.

Something isn't working. I have 2 VAX nodes with VMS 7.3 and an ALPHA
node with VMS 7.3-1 with all necessary patches applied.

I have a shadow set of two members each of which has a direct connection
to a VAX. I needed to take a VAX down (I need to increase the number of
global sections so I can install some layered products) so I figured I
would test the minicopy stuff. The shadow set is mounted on all 3
nodes.

So, FROM THE ALPHA, I dismounted one physical member of the shadow set
with /POLICY=MINICOPY. OPCOM mentioned some stuff about a write bitmap
being created. I didn't shut down the VAX, but wanted to make sure the
command worked properly first and that a minicopy would occur on MOUNT.

Here's the command: MOUNT/CLUSTER/NOASSIST/POLICY=MINICOPY/CONFIRM
(then shadow set name, shadow member names and volume label, of course).

There are several problems with this command. First problem: on VAX it
says that the POLICY=MINICOPY stuff is not a recognised option. OK,
perhaps the MOUNT has to be issued from an ALPHA. In that case,
however, the syntax shouldn't be mentioned in the VAX help.

I then tried the command on ALPHA. Second problem: /CONFIRM says that a
FULL shadow copy should be performed. Maybe this is just the standard
boilerplate text, but shouldn't it mention MINICOPY instead of full copy
if that is what it is trying to do?

I said yes to the question. (Note that I didn't specify the OPTIONAL,
so that the mount would fail if MINICOPY couldn't be executed.) The
mount was successful. OPCOM gave some informational messages about
write bitmaps (which I don't recall seeing before when mounting a member
back into the shadow set). Third problem: based on the speed of the
copy operation currently in progress, IT APPEARS THAT IT IS DOING A FULL
SHADOW COPY.

According to what you said in your previous post, since I'm not taking
the ALPHA down (and even issued the DISMOUNT and MOUNT commands from the
ALPHA), then the command should work. Even if for some reason it
doesn't, then the fact that I specified POLICY=MINICOPY without the
OPTIONAL keyword on the mount command should have caused my mount
command to fail. At least, this is what HELP says.

A related question: What is the purpose of specifying
MOUNT/POLICY=MINICOPY on the first mount of a shadow set (say, after a
cluster reboot)? Is it needed to enable the DISMOUNT/POLICY=MINICOPY
later (which would explain my problem, but HELP makes it sound like just
the DISMOUNT/POLICY=MINICOPY command is enough)? Is it needed to enable
a minicopy if one member of the shadow set unexpectedly goes away then
comes back (say, due to a connectivity problem, or an unscheduled crash
and reboot of the node hosting it) (however, if the scenario above
doesn't work, I don't expect this to work either).

Unfortunately, I don't have any screen shots since the one node in my
cluster which will work with a graphics monitor is currently awaiting a
capacitor replacement; I'm typing away at a VT320. However, based on
the various messages (except for the first two problems mentioned above,
which are essentially typos, apparently) it appeared that EVERYTHING was
working as I expected it to after reading your last post, until the FULL
copy operation started.

The disk in question is 9GB. I would guess that just a few KB were
modified while the one member was dismounted. Thus, I would expect the
MINICOPY to take a few seconds or, at most, a few minutes. However, the
copy operation is now 6% complete after about 20 minutes, so we are
looking at a few hours (normal for a full copy operation). Bummer!

Relevant Pages

  • Re: long, boring explanation of minicopy (and HBVS, in general)
    ... > from minicopy is the one where the Alpha is shut down. ... > as long as the shadow set is mounted on an Alpha (even if its connection ... > is MSCP through a surviving VAX), ... this would only apply to a shadow set with both members on ...
    (comp.os.vms)
  • shutdown of a node, shadow copies and merges
    ... all disks (with one exception not important to ... products on another VAX and installed some patches on the ALPHA, ... I got a shadow copy on the shadow set with a member on the ...
    (comp.os.vms)
  • Re: two questions about MINICOPY
    ... > connection to the shadow set fails), can I expect that a) a minicopy ... the dismount in a controlled way. ... in a mixed cluster, there is a shadow set mounted only on VAX ...
    (comp.os.vms)
  • Re: shadowing questions
    ... >> While full minicopy support on VAX ... >> the shadow set have a direct connection only to VAX machines. ... I have 2 VAXes and 1 ALPHA in the cluster. ... > You can also use HBMM on disks that are directly connected to VAXes, ...
    (comp.os.vms)
  • Re: two questions about MINICOPY
    ... a minicopy worked fine with a shadow set with one node ... on a VAX and one node on an ALPHA, doing the dismount and mount from the ... I have a shadow set split across two VAX nodes, ...
    (comp.os.vms)