[Info-vax] Shadow Volume Copy

[Michael Moroney]

AEF <spamsink2001 at yahoo.com> writes:

>> >> 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_.

>No. From

>http://h71000.www7.hp.com/doc/732final/aa-pvxmj-te/aa-pvxmj-te.html

>"The shadowing software always selects one member as a logicalmaster
>for any merge operation, across the OpenVMS Cluster.Any difference in
>data is resolved by a propagation of the informationfrom the merge
>master to all the other members." [sic: Spacing and the lack thereof
>are as copied and pasted over.]

>I wouldn't be the least bit surprised if this "logicalmaster" is the
>"master" disk from the SDA output.

I just checked.  The initial read does go to the random drive, and then
a datacheck IO is done to the other member(s), and if they are different,
then the disk identified as the master is used a source to make all 
members 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.

>You can't have shadowing until the system is far enough in the boot
>process to start and run it. Consequently, until that point, only the
>boot disk is used. If there is some writing to that disk before that
>point, the other members of the system disk shadow set must get caught
>up. Incidentally, this is one way to determine which is the boot disk.
>If there is another way (especially if it's a more convenient way), I
>am all ears.

There is some special code in the shadow driver for booting.  This code
does know enough to look for other members but that may wait until the
system disk is "mounted".  Before then there shouldn't be writes since
they aren't synchronized with anything else in the cluster, although
I think there may be some exceptions (the "current" parameters for one)

>As for crash dumps, I don't think that the system can run the bugcheck
>code (or whatever it's called) and volume shadowing code concurrently.
>And I'd think that would mess up your dump, anyway. Consequently, it
>writes to the boot device unless you set it up to dump to some other
>disk. But you can't dump to a shadow set, as far as I know. (That's
>aside of the trivial case of a single-member shadow set, of course!)

The bugcheck code is written by the crash dump code/console, which knows 
nothing of shadowing.  The data goes to the boot device (ignoring the 
dump_dev console parameter).  There is something funny within shadowing
or SDA that deals with the dump data only being on one drive.  I don't 
remember the details.  A common problem was the merge code wiping out the 
last dump.