Re: How clean is the snapshot when dismounting a member of a shadow set?

From: H Vlems (hvlems.nieuw_at_zonnet.nl)
Date: 10/11/03 

Date: Sat, 11 Oct 2003 16:14:53 +0200

"Phillip Helbig---remove CLOTHES to reply" <helbig@astro.multiCLOTHESvax.de>
schreef in bericht news:bm8s6k$dnl$1@online.de...
> In article <bm8nnk$kkpv0$1@ID-143435.news.uni-berlin.de>, "H Vlems"
> <hvlems.nieuw@zonnet.nl> writes:
>
> > Interesting question. My initial reaction to the question was that you'd
end
> > up with the same situation as running BACKUP/IMAGE/IGNORE=INTERLOCK on
the
> > disk. The only difference being that backup takes time to complete and
the
> > actual on-disk state of an open file is never known for sure.
>
> Right, it's faster. (Well, when I replace the disk I remove with
> another one, a shadow copy will happen, but I don't care about that
> since I don't have to wait for it.)

OK, that's something I can relate to.

>
[database stuff removed]
>
> > But perhaps you could elaborate on what you consider "side effects" ?
>
> I'm mainly concerned with cloning system disks. That is, after a
> successful upgrade when I have a valid shadow set, remove one member and
> use it for the system disk on another machine, replacing it with a fresh
> disk (which will be the target of a shadow copy). There are a lot of
> open files on a system disk, but presumably most of these are just open
> for reading. I'm sure they don't change on disk under normal
> circumstances; the question is if they can become corrupted when I do
> the dismount. (There are also log files open, but I don't care about
> these since they are of no interest on the other machine. SYSUAF etc
> are not on the system disk at all.)

On a quiescent system only OPERATOR.LOG and the event log are written to.
Part of the data may remain in cache and thus missing on the disk. If you
want to create clones then that shouldn't bother you.
>
> The other alternative, of course, is to shut down the system, replace
> one of the disks, and reboot. It means an additional reboot. Actually,
> with a three-node cluster, this is not really a problem. It does take
> more time, though.
>
> Now that I think about it, perhaps the best thing to do is, after the
> upgrade, move to a THREE-member shadow set. That way, if I shut down
> the system, remove a disk and reboot, I end up with a two-member shadow
> set (which is what I want) without a shadow copy!

Correct.
>
> This leads to another question: can I have one of the members of a
> SYSTEM-DISK shadow set be directly connected to another machine in the
> cluster (even one with different architecture) and only MSCP served to
> the system using it as a system disk, as long as I add this member after
> all machines in the cluster are up and running (or at least if I don't
> boot from it)? If I can do this, the extra reboot would be worth the
> trouble of avoiding an additional shadow copy.
>
AFAIK host based shadowsets cannot be MSCP served. The DSA devices are
listed without an ALLOCLASS prefix. If you use a shadowset member all by its
own then VMS will mount that volume read-only. No idea how VMS would react
when it encounters such an isolated member as a systemdisk.

Relevant Pages

  • Re: Sizing up Disks with Shadowing
    ... Not as soon as the initial shadow copy is ready at least, ... the master. ... member being added to a 2 member set), data is read from either of the two ... place without the need to lock disk blocks or block I/O, ...
    (comp.os.vms)
  • 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: physical drive replacement
    ... >> My first problem is determining which of the 2 physical drives in stripeset ... DELETE the disk, quiesce the bus and perform the physical swap, ... > and mount it into the shadow set, which should trigger a shadow copy ...
    (comp.os.vms)
  • Re: Suggestion for INSTALL PURGE and SHUTDOWN.COM
    ... > re-integration of a disk into the shadow set). ... dismount all shadow sets with members with direct ... sure that the subsequent MOUNT command (after the reboot) is also done ...
    (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)