Re: Sizing up Disks with Shadowing

On Aug 11, 3:31 pm, AEF <spamsink2...@xxxxxxxxx> wrote:
On Aug 11, 2:21 pm, moro...@xxxxxxxxxxxxxxxxxxxxxxx (Michael Moroney)
wrote:



jbriggs444 <jbriggs...@xxxxxxxxx> writes:
On Aug 10, 4:13 pm, Ken Fairfield <ken.fairfi...@xxxxxxxxx> wrote:
On Aug 10, 12:53 pm, Jan-Erik S=F6derholm <jan-erik.soderh...@xxxxxxxxx>
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.
.

Relevant Pages

  • Re: Sizing up Disks with Shadowing
    ... Not as soon as the initial shadow copy is ready at least, ... A "master" member of a shadowset is only meaningful during a merge ... place without the need to lock disk blocks or block I/O, ...
    (comp.os.vms)
  • Re: Shadow Volume Copy
    ... set member must it consider as master,... ... describe a member as "master" is pretty much meaningless. ... No, in a merge, one disk is read (which one is determined by queue ... disk in a shadow set will be its "master". ...
    (comp.os.vms)
  • Re: Shadow set problem finally solved
    ... pure-vanilla problem of a shadow set having a forced ...  Do an back/image on the member ... and if not a boot disk the following [after being certain nothing will be ... My temp file technique solves the problem outright. ...
    (comp.os.vms)
  • Re: Shadow Volume Copy
    ... describe a member as "master" is pretty much meaningless. ... written back to the other members. ... two merging shadow members A and B differ in blocks 1000 and 2000, ... "master" disk from the SDA output. ...
    (comp.os.vms)
  • Re: Shadowed System disk questions
    ... A few things to think about once you have system disk shadowing enabed: ... render your system disk unusable), add a third member, wait for the ... shadow copy to complete, and dismount it before applying the ... the desired disk in the boot command to make sure you boot to the ...
    (comp.os.vms)
Loading