[Info-vax] INIT/SHADOW

[IanMiller]

On Feb 20, 12:39 pm, hel... at astro.multiCLOTHESvax.de (Phillip Helbig---
undress to reply) wrote:
> In article <ijq0sd$a9... at pcls6.std.com>, moro... at world.std.spaamtrap.com
>
>
>
> (Michael Moroney) writes:
> > Shadowing uses metadata on the disk, the SCB (which is the first block
> > of BITMAP.SYS) to determine shadowset membership, the time of the last
> > transition and so forth, as well as some info in the home block (whether
> > the volume was properly dismounted) to determine whether two disks were
> > part of the same shadowset and whether a merge is necessary if they
> > were.  (I'll ignore bitmaps/minicopy etc).
>
> > In theory a program could make two non-shadow disks into a shadowset
> > needing no merge by sticking the correct magic bits into the SCB.  In a
> > way INIT/SHADOW has such code (it initializes the disks identically and
> > then makes them appear to be part of a shadowset) but I know of no
> > other such code.
> > If you take two identical, nonshadowed disks and make a shadowset from
> > them, the code will mark one as the source and copy onto the second.
> > It doesn't know they're identical.
>
> Sounds logical.  However, HELP says that INIT/SHADOW/ERASE will erase
> the volumes sequentially, and suggests for big disks to do just
> INIT/ERASE and then later do INIT/SHADOW/NOERASE.  It doesn't say so
> explicitly, but the impression is that INIT/SHADOW/NOERASE won't cause a
> MERGE (the whole point of doing /INIT/ERASE in parallel is to save
> time).  So, in this case, I do INIT/SHADOW on two disks which were not
> previously part of a shadow set, but which have been erased.  There must
> be some information which says "this disk has been erased and since then
> nothing has happened", but probably not part of the SCB, since the disks
> aren't yet part of a shadow set.  Where is this information stored?


If the disks are erased then a merge will be faster as the contents of
the disks will be the same. Perhaps that's why.