[Info-vax] Sizing up Disks with Shadowing

[Michael Moroney]

jbriggs444 <jbriggs444 at gmail.com> writes:

>On Aug 10, 4:13 pm, Ken Fairfield <ken.fairfi... at gmail.com> wrote:
>> On Aug 10, 12:53 pm, Jan-Erik S=F6derholm <jan-erik.soderh... at telia.com>

>> > As far as I know, there is no "master" in a VMS shadow set.
>> > Not as soon as the initial shadow copy is ready at least,
>> > after that, the two (or three) disks are equal.
>>
>> Actually, one member of a shadow set will be designated
>> the master.  I believe this is used as the source during
>> shadow copies. Otherwise, all members are treated as
>> equal.

>In the event of a tie on an improperly dismounted volume I assume that
>a merge operation ensues and it's random chance which volume provides
>the canonical data for any particular block number.  The merge
>operation proceeds, reading from each disk and writing to all others
>in parallel.  While the merge operation runs in the background, the
>shadow set is on-line and serving requests.  Read requests from un-
>merged space are read from a random member, written to the other
>members and the data is returned to the user.  Active writes to un-
>merged space are handled normally.

A "master" member of a shadowset is only meaningful during a merge
operation, and then only for blocks above the merge fence (boundary
between where the merge has and hasn't completed)

The merge read algoritm is to read from any member, compare the data to
that on the other member(s), and if it matches you're done.  If there is a
mismatch, data is read from the unit designated as the "master" and
written to the other(s) before it's returned to the caller.  This is the
only real use of a "master".  Note that in a copy operation (a third
member being added to a 2 member set), data is read from either of the two
disks (assuming a merge is also not pending) then written to the new
member.  All full members are assumed to be identical so there is no need
for a master.

This seemingly odd algorithm exists to allow merges and copies to take
place without the need to lock disk blocks or block I/O, ordinary I/O
continues to take place.

>The point I'm trying to make is that there isn't a single statically
>identified volume that is "the master".

There is, but only for merge operations.