[Info-vax] Sizing up Disks with Shadowing

[AEF]

On Aug 11, 3:31 pm, AEF <spamsink2... at yahoo.com> wrote:
> 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

Wait, there's more!

>From the DCL Dictionary:

SHDW_MASTER_MBR (Alpha/I64 only)  	 String  	 The name of the master
member unit that will be used for merge and copy repair operations and
for shadow set recovery operations.