[Info-vax] INIT/SHADOW

[Michael Moroney]

helbig at astro.multiCLOTHESvax.de (Phillip Helbig---undress to reply) writes:

>In article <ijq0sd$a9d$1 at pcls6.std.com>, moroney 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's too bad they couldn't be bothered to make INIT/SHADOW/ERASE work
in parallel at minimum, and to try to make the erase operation as quickly
as possible.

>  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).

It won't.  It messes with the data structures to make the drives appear
to have been in a shadowset in the distant past (so that they won't be
used as a source if, for some reason, you tried to make a shadowset
out of another shadowed drive and one of the erased members).

>  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",

There really isn't.  INIT/SHADOW/NOERASE has the potential to have
shadowed drives have different data, which can cause really strange
errors (read data from block X, read block X again and get *different*
data!) but this shouldn't be an issue since none of this data will be
in files.  To access this data you have to 1) turn off highwater; 2) 
deliberately read data past file EOF marks (and consider it valid) and
3) hope that disk caching doesn't save your butt.

> but probably not part of the SCB, since the disks 
>aren't yet part of a shadow set.

Actually the disks do look like dismounted shadowset members after
an INIT/SHADOW.