[Info-vax] Sizing up Disks with Shadowing

[AEF]

On Aug 11, 2:21 pm, moro... at world.std.spaamtrap.com (Michael Moroney)
wrote:
> jbriggs444 <jbriggs... 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.

There is another use of the master member: to identify the boot disk
of a system disk shadow set. Unfortunately, having VMS V6.2 on VAX, I
have to run SDA to see what it is. (Actually, I haven't seen this
documented anywhere; I know this only by checking it whenever I get
the chance. If what I say here is NOT true, please post.)

AEF