Monitoring shadow set merge status

[John A. Beard]

Hi folks,

We are developing a procedure whereby a spare third shadow set disk is mounted into the existing two disk shadow set on a fixed interval basis. Once fully merged, we then want to dismount/remount (private) the 3rd shadow set member and perform an archive backup on our ADSM server.

I need to find the correct lexical that would allow us to check the merge status so we can safely dismount it once complete. I have initially tried using SHDW_MBR_MERGE_DONE, but this ended up going into a loop.

$ If F$GETDVI("''SHAD3_DISK'","SHDW_MBR_MERGE_DONE") .NES. "TRUE" THEN GOTO SHADOW_BUILD_STATUS

Is there a better way to have the procedure informed as to when the merge is 100% complete... thanks John

[Robert Brooks_1]

Perhaps you should check the documentation for that item code.

That item code returns an integer, not a boolean.


-- Rob

[Volker Halle · Accepted solution]

John,

what you are describing is a shadow FULL COPY operation not a shadow MERGE. So you need to wait until the SHADOW COPY is done on the 3rd member, before removing it from the shadowset.

Depending on your version of OpenVMS, you may also want to familiarize yourself with the shadowing minicopy concept available since V7.3. This will greatly speed up bringing the 3rd member back into the shadowset.

The following F$GETDVI item codes would be of interest to you:

SHDW_MBR_COPY_DONE - The percent of the copy operation completed on this member unit

SHDW_CATCHUP_COPYING - TRUE or FALSE to indicate whether the device is a member that is the target of a full copy operation

Volker.

[Wim Van den Wyngaert]

It returns a string "The percent of the merge operation completed on this member unit", not true or false. And is not available on VAX.

But don't you need SHDW_MBR_COPY_DONE instead because a copy is done with adding a disk to the shadow set ?

Wim

[Volker Halle]

John,

here is an example:

$ sho dev dsa0

Device Device Error Volume Free Trans Mnt
Name Status Count Label Blocks Count Cnt
DSA0: Mounted 0 AXPVMSSYS 3211650 450 1
$1$DKA200: (PFRWIW) ShadowSetMember 0 (member of DSA0:)
$1$DKB200: (PFRWIW) ShadowCopying 0 (copy trgt DSA0: 11% copied)

$ write sys$output f$getdvi("$1DKB200:","SHDW_MBR_COPY_DONE")
14

Volker.

[John A. Beard]

Thanks to everyone for the prompt reply.

I will take what you have given me and test it out shortly.

FYI The version of VMS is 7.3-2. As regards the issue with mini copy, the current plan would see the third disk remain dismounted for a week at a time before repeating the exercise. Being the system disk, I'm not sure if the weekly copy is a little overkill, but Buisness has demanded that schedule for the moment.

This whole business arrose out of a situation where the server would not boot off the existing two disk system shadow disk...too long a story for here.

[Jon Pinkley]

RE:"This whole business arrose out of a situation where the server would not boot off the existing two disk system shadow disk...too long a story for here."

If that is the purpose of the exercise, then wouldn't it be more prudent to have a snapshot of the state from the last know working boot? If the system isn't booted for extended periods of time, the startup files could have been changed, deleted, etc. and your weekly snapshot will be of an untested configuration.

Jon

[John A. Beard]

We had to restore the system disk from tape in order to build a bootable disk. The initial third shadow disk copy was of this valid disk.

[Jon Pinkley]

My point was that it is easy to make a system disk not bootable but still usable while the system is up. An analogy is removing the power cable to your car's starter after the car is running. Everything works fine until you turn the engine off.

What is the purpose of taking a weekly snapshot, and what is the source of the snapshot? If it is the running system, and it hasn't been booted since the last snapshot, you have no guarantee that the snapshot is bootable.

If the purpose is to take a system backup, then, in my opinion, doing it your way is better than a backup/ignore=interlock.

If your system generally stay up for > 1 week, then I would still reconsider using minicopy. It always takes less time to do minicopy than a full copy, even if 100% of the disk has to be copied, due to the copy algorithm used by full copy. After learning that, I have wondered why it wasn't possible to have a 100% dirty bitmap created for the full copy case.

I thought the implied purpose was to have a known good system disk that could be used in case the live system shadow set would not boot.

Jon

[John A. Beard]

I am glad to say that the 3rd disk scenario has worked out really well (using MINICOPY).

The once-a-week copy pattern may have sounded like overkill, but this was simply an initial demand from business after the initial two day loss of access to this system. Any further loss of access beyond that point would have generated losses in the tens of millions...

Thanks again to all those who contributed to the thread.

John