Operating System - OpenVMS
1745809 Members
3608 Online
108722 Solutions
New Discussion юеВ

VMS Puzzle #2: Using HBVS to allow read-only snapshot to be used system wide

 
SOLVED
Go to solution
Jon Pinkley
Honored Contributor

VMS Puzzle #2: Using HBVS to allow read-only snapshot to be used system wide

VMS Puzzle #2: Using HBVS to allow read-only snapshot to be used system wide without preventing a minicopy when the removed member is reintroduced into the shadow virtual unit.

This is a VMS brainteaser, similar in spirit to the one I posted on Christmas, Dec 25, 2007 08:45:03 GMT (not a real problem, since I know the answer).

Problem: You want to make a static snapshot of a disk prior to some testing that will modify a small portion of the shadowset virtual unit (DSA) disk. You want to be able to mount the snapshot (removed SSM) /system /nowrite so it can be used as a reference copy of the state prior to the test. You have a shadowing license and available disks, and want to use HBVS to remove a member for the static copy. Since only a small portion of the shadowset virtual unit disk will be changing, you want to be able to use minicopy to return the snapshot member to the virtual unit, thus avoiding a full shadowcopy operation to bring the member back to synchronization with the shadow virtual unit.

Summary: A shadowset member (SSM) is removed, and then without dismounting the original shadow virtual unit (DSAxxx:), how can the removed SSM be mounted /system while still allowing the removed member to be returned to the shadowset with a minicopy instead of a full copy?

I will award points when the solution has been disclosed. I will post a logfile showing an example of the method.

P.S. I suggest you try any solution before you post it, as if a proposed solution does not work, I will post a log showing any errors encountered. The method I discovered should work with any version of shadowing supporting the minicopy operation (I have tested with 7.3-2 with the HBMM patch, but it should not rely on enhancements in that patch).

Perhaps someone else has discovered the method, but I have never seen or heard of it. I talked with three VMS engineers at bootcamp that have worked on the HBVS, and they were not aware of the technique either.

If I discussed this with you at bootcamp, please don't disclose the answer, so others will have a chance.
it depends
28 REPLIES 28
Jan van den Ende
Honored Contributor

Re: VMS Puzzle #2: Using HBVS to allow read-only snapshot to be used system wide

Jon,

having NO system available at the moment, this will be only a mental operation. What I would do, is take out one member, make a (physocal) backup thereoff, rejoin the talen out member. Then mount the backup copy privately, change its volume label, and mount it system (cluster-) wide,
And I would spend some time in setting up the concealed devices to make the (relevant parts of) the snapshot transparantly available.

There may well be a more elegant/quicker solution, in which case I am curious & interested!

Proost.

Have one on me.

jpe
Don't rust yours pelled jacker to fine doll missed aches.
Uwe Zessin
Honored Contributor

Re: VMS Puzzle #2: Using HBVS to allow read-only snapshot to be used system wide

I don't have a system available, either, but I would change the volume label and clear the shadow generation number, too.

If I remember correctly, this is all located in the storage control block. So you might even be able to mount the volume /FOREIGN, save the block with a simple DCL READ, update with a WRITE - I assume you know the SCB layout, of course ;-).

That should give the disk a new identity which allows a system-wide MOUNT/NOWRITE.

When you want to put the disk back into the shadow-set, dismount it, restore the SCB and MOUNT/...
.
Jon Pinkley
Honored Contributor

Re: VMS Puzzle #2: Using HBVS to allow read-only snapshot to be used system wide

-----------------------
RE: Physical backup of removed member.

Yes, that would work and allow the removed member to be returned to the shadowset without a full copy. But it still requires a lot of I/O to make the physical backup, if the device is large. That's not the answer I was looking for.
-----------------------
RE: Saving and restoring the SCB.

The disk label is stored in the HOMEBLOCK, what is stored in the SCB is the volume lock name which normally is the same as the label.

It is possible to do something close to what Uwe suggested, but there is a much easier and less error prone way.

If you are interested is how that can be done, I have attached a logfile doing this using the freeware DISKBLOCK program, but it is not supported, and there is an easier way that doesn't do anything in an unsupported manner.

This isn't the method I am referring to. My method is much easier and uses fully supported operations that don't involve lying to the VMS shadowing software, which is essentially what restoring the SCB is doing (it is telling the shadowing software that nothing has changed on the volume, when in fact it has).
-----------------------
Ok, ready for round two. (As stated before, I will award points when I close the issue).

Jon
it depends
Wim Van den Wyngaert
Honored Contributor
Solution

Re: VMS Puzzle #2: Using HBVS to allow read-only snapshot to be used system wide

Tested it and it works but your system may not depend on a fixed label :

set env/clu
do set vol dsa1/lab=wim

dism disk1/poli=min=opt

set env/clu
do set vol dsa1/lab=disk1

mount disk1 wim/sys/nowr

dism disk1

set env/clu
do set vol dsa1/lab=wim

mount dsa1 wim/sys/shadow=disk1

set env/clu
do set vol dsa1/lab=disk1

Wim
Wim
Wim Van den Wyngaert
Honored Contributor

Re: VMS Puzzle #2: Using HBVS to allow read-only snapshot to be used system wide

Here is the full log in enclosure.

Wim
Wim
Wim Van den Wyngaert
Honored Contributor

Re: VMS Puzzle #2: Using HBVS to allow read-only snapshot to be used system wide

BTW : it would be a nice improvement for VMS (probably in a version I will never use) if one could mount the disk whatever the label. Just like when you do when mounting a disk without /sys.

Wim
Wim
Robert Brooks_1
Honored Contributor

Re: VMS Puzzle #2: Using HBVS to allow read-only snapshot to be used system wide

BTW : it would be a nice improvement for VMS (probably in a version I will never use) if one could mount the disk whatever the label.

--

$ MOUNT /OVER = ID

tends to work rather well for me . . .


-- Rob
Jon Pinkley
Honored Contributor

Re: VMS Puzzle #2: Using HBVS to allow read-only snapshot to be used system wide

Wim,

Yes, that is the method, assuming the original volume label in your example (May 26, 2008 14:50:46 GMT) was disk1 to begin with.

As Wim described, the "trick" is to change the volume label of the shadowset VU BEFORE the member is removed, then remove the member with /policy=minicopy, then change the label of the DSA Virtual Unit (VU) back to its original label. Now the removed SSM can be mounted /system (or /cluster) and since its SCB knows it was a shadow set member, the member is automatically mounted software write locked. When it is time to return the member to the shadow set, the VU's label must be changed back to the label it was when the member was removed. Otherwise, the minicopy bitmap won't be used. So there are two short periods of time when the volume label in the shadowset's HOMEBLOCK will be different than its original value, but these can be short windows of time, and very few things rely on the volume label. The logical name created by mount, f$getdvi(disk,"LOGVOLNAM"), does not change when the disk volume label is changed, so only things paying attention to f$getdvi(disk,"VOLNAM") would see the changed volume name. It is not necessary to wait for the minicopy to complete before changing the label back to its original value, so the duration of the changed label can be quite small. However, if you do have software that is looking at the actual label, it is possible that it will see the value of the label during the short period when it was changed. And if the system crashes during that window, the mount commands using the old labels will fail.

Other than the original label changing for these two short durations, I am not aware of any downsides to this method. If you absolutely can't change the volume label on the VU, then I am not aware of any supported way to get the removed member back into the shadowset without a full copy. In my previous attachment, I show a way this can be done (as an academic example), but it involves restoring the SCB, and that should be avoided if your data is important.

Since you can have up to six minicopy bitmaps per VU, and minicopy bitmaps are currently single mastership, you can have multiple snapshots active at the same time, each taken at different times. So you could for example have periodic rotating snapshots, where each member would be brought back into the shadowset with a minicopy before being removed again.

I am attaching notes I made in January, 2008.

If anyone is interested, I can attach some additional log files giving more details about why this method works, and show more details from SDA, DISKBLOCK and LDDRIVER traces. But if you really want to understand how it works, there is no substitute for doing some experiments yourself. LD devices are great for this, as they don't need to be big, and if you have to do a full copy, it still won't take a long time.

If you do the experiments, I suggest looking at the SCB and homeblock before and after a set volume/label and before and after removing a shadowset member. Grab the DISKBLOCK utility off the freeware. As long as you use

DISKBLOCK> select/nowrite device_name

then it should be reasonably safe. And before using it, read the help. DISKBLOCK knows how to format the SCB and how to find it, so it is reasonably easy to use for that purpose. See my previous attachment for some examples.

The SCB in the removed member still has the original volume lock name, but since this is a read only volume, the volume lock name in the SCB is never updated. Changing the label in the homeblock is sufficient to have mount create a new volume lock name

Would anyone be interested in a VMS Technical Journal article showing how this works, the SCB fields involved, that HOMEBLOCK fields involved, etc.?

I would be interested in hearing any downsides to doing this. Specifically what problems can changing the Shadow VU's volume label cause?

Note: if your purpose is just for backup and not for an online reference copy, you probably don't want to use this method, since the label has been changed. The backup process can just mount the removed member privately, so there shouldn't be a problem if it has the original label.

Jon
it depends
Jon Pinkley
Honored Contributor

Re: VMS Puzzle #2: Using HBVS to allow read-only snapshot to be used system wide

Hi Rob,

It was nice meeting you face to face at bootcamp.

Concerning Wim's comment about the label, I am quite sure he meant it would be nice if you could mount/system any disk you can mount privately. I.e. I think he would like to be able to mount multiple shared volumes with the same label without getting a %MOUNT-F-VOLALRMNT error.

Wim,

What problem are you trying to solve by allowing multiple shared volumes to have the same label? Windows write "signatures" to the disks to prevement multiple instances from being mounted at the same time, and this is in my opinion, at least as restrictive as what VMS does. At least VMS allows you to easily change the label. If you have an EVA and use it to snapshot a Windows disk, you won't be able to mount that disk on the same system without using a utility to change the signature (as far as I know it, this utility isn't part of stock windows server, just like DISKBLOCK isn't part of stock VMS.)

Allowing multiple shared volumes with the same label to be mounted in the cluster would require a redesign of the way things work, i.e. there isn't an easy general solution I can think of. VMS needs something unique that can be used as the volume lock name, and in the case of a shared volume, there are many reasons that this something needs to come from the media. and that something is the volume label. In the case of a read-only volume mounted privately, VMS creates a volume lock name from the SCSNODE name and S0 (system) address of the device's UCB, a combination that is guaranteed to be unique for the node/device. I suppose it would be possible to provide a way to specify a volume lock name for $MOUNT to use, and have that be what got loaded into the VCB. But if it were possible to override the volume label, how could VMS protect itself from someone mounting the same disk via two different paths, for instance when allocation classes are configured incorrectly? Allowing it for read-only access may be safe, but this is just off the top of my head, so I am probably overlooking many other issues.

Jon
it depends