[Info-vax] Sizing up Disks with Shadowing

[jbriggs444]

On Aug 10, 4:13 pm, Ken Fairfield <ken.fairfi... at gmail.com> wrote:
> On Aug 10, 12:53 pm, Jan-Erik Söderholm <jan-erik.soderh... at telia.com>
> wrote:
>
> > tadamsmar wrote:
> > > Can I introduce a larger disk into a shadowset?
>
> > > I plan to replace 2.1 gig disks with 9 gig disks soon.
>
> > > I was thinking I could do it by just putting them in the shadow set
> > > and then switching the master.
>
> > 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.

That is not the algorithm that I recall.  I've been out of the VMS biz
for years though, so take what I say with a grain of salt.  Half of
the following is based on documentation and presentations.  The other
half is "how would I have implemented if it were me?"

If you are merging a new member into an established shadow set there
is, of course, no ambiguity.  The existing shadow set is the master.
The newly added member will be overwritten.  *SPLAT*.  If this fact is
a concern, the /CONFIRM option on $ MOUNT may be useful.  [Gotta watch
out for those unattended boot procedures]

If you are forming (i.e. re-mounting) a shadow set from two or more
candidate members, then the shadow set sequence number on each
prospective member is examined.  The highest sequence wins.  The
theory is that if a member had failed out of the shadow set, its
sequence number will have remained unchanged while the sequence number
(s) on the surviving member(s) will have been incremented to reflect
the state change.  The highest sequence number thus reflects the most
recent member(s).

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.

In the event of a tie on a properly dismounted volume, all members
tied for first are immediately valid.  No merge operation is required.

If you wish to override the sequence number scheme you can choose to
form a single member shadow set from a chosen member and then add the
other members to the resulting shadow set with a copy operation.

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