[Info-vax] Shadow Volume Copy

[AEF]

On Mar 27, 4:49 pm, moro... at world.std.spaamtrap.com (Michael Moroney)
wrote:
> AEF <spamsink2... 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_.

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.

Moreover, I wouldn't want a random mix of data from multiple disks.
Pick one and go with it!

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

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!)

AEF