[Info-vax] Shadow Volume Copy

[Michael Moroney]

AEF <spamsink2001 at yahoo.com> writes:

>On Mar 25, 10:15=A0am, Jan-Erik S=F6derholm <jan-erik.soderh... at telia.com>
>wrote:
>> Ramon Jimenez wrote:
>> > I tried it but when I could not find the way to tell VMS which shadow
>> > set member must it consider as master,...
>>
>> There is no "master". The two disks are equal.

>Well, yes and no:

>            ----- SHAD Device summary for $1$DKA0  -----

>Device $1$DKA0 ... Master Member
>  Index 0 Status     000000A0 src,valid
>  UCB 8717A8F0   VCB 878BA900   Unit Id. 11610000 00000001
>        Member Read Bias 0000002A
>Device $1$DKA100
>  Index 1 Status     000000A0 src,valid
>  UCB 878A1C40   VCB 878BA580   Unit Id. 11610064 00000001
>        Member Read Bias 0000002A

>        *** I/O request queue is empty ***

It's been quite a while, but as I recall the info that SDA uses to
describe a member as "master" is pretty much meaningless.

>I believe this breaks the tie for merge operations.

No, in a merge, one disk is read (which one is determined by queue
lengths, read bias etc.), then compared to the data on the other member(s)
and if different, written back to the other members.  The net result is if
two merging shadow members A and B differ in blocks 1000 and 2000, it's
quite possible that during the merge, the data in A's Block 1000 is what
gets written to B's Block 1000, and the data in B's Block 2000 is what's
written to A's Block 2000.  What's important is after the merge, the two
drives are _identical_.

> Also, the boot
>disk in a shadow set will be its "master". But yes, for this purpose,
>the disks are identical.

There is some funny business for system disk shadowsets, esp. regarding
system dumpfiles, which get written by the console code only to the
boot device.  I don't remember how that works.