topic Re: First shadow copy in Operating System - OpenVMS

First shadow copy

Wim Van den Wyngaert — Thu, 12 Aug 2004 04:13:07 GMT

I just discovered a 7.3 (?) feature that I was unaware of. INIT/ERASE/SHADOW=(X,Y,Z) LAB.

This allows to initialize a complete shadow set without doing a shadow copy. Disadvantage : it does the init of Y after X has completed, not in parallel.

I don't have a system to play with so my question is : what happens if I ommit /ERASE ? Will the shadow copy be done ?

Btw : on my GS160 initializing 36 GB took 30 minutes voor the local disk and 35 minutes for the mscp served (no FC between them) remote disk (rather fast, I can't explain why).

Wim

Re: First shadow copy

Wim Van den Wyngaert — Thu, 12 Aug 2004 04:22:47 GMT

Btw2 : on my GS160 the init is 3-4 times faster than the shadow copy.

Re: First shadow copy

Jan van den Ende — Thu, 12 Aug 2004 04:47:46 GMT

Wim,

HELP INIT /ERASE explaines it so much better then I could, have you already read that?

Jan

Re: First shadow copy

Wim Van den Wyngaert — Thu, 12 Aug 2004 04:50:06 GMT

Yes jan. But what is the use without /erase.

Wim

Re: First shadow copy

Uwe Zessin — Thu, 12 Aug 2004 05:08:37 GMT

Using the /ERASE makes sure that each member has the same contents. If you leave the qualifier off, then the first merge operation can take quite long if the members still have different contents.

If I remember correctly, /ERASE will mark the volume as such so that any future file deletions will carry out an ERASE-ON-DELETE operation. That can take quite some time on large files...

Re: First shadow copy

Wim Van den Wyngaert — Thu, 12 Aug 2004 05:14:33 GMT

Uwe,

/ERASE is erasing the disk during 30 minutes. So it's not just marking the disk for erase. set volume/erase is marking the volumeset.

Wim

Re: First shadow copy

Antoniov. — Thu, 12 Aug 2004 05:16:27 GMT

Uwe,
SET VOL /NOERASE avoid erase on delete.

Antonio Vigliotti

Re: First shadow copy

Uwe Zessin — Thu, 12 Aug 2004 05:23:58 GMT

I know that, Wim. You have written it in your first message and I wrote that "/ERASE makes sure that each member has the same contents".

If you leave off the /ERASE it will not overwrite all blocks of all members, so they retain their previous contents which are very likely different.

Now, if you mount this new shadow set and get a merge operation - guess what happens?

Re: First shadow copy

Wim Van den Wyngaert — Thu, 12 Aug 2004 05:35:47 GMT

Uwe,

In the mean time, I found a test system. I did a init without erase and then mounted the shadow set. The init was done in a few seconds. The mount didn't result in a shadow merge or copy !!!

Wim

Re: First shadow copy

Jan van den Ende — Thu, 12 Aug 2004 05:36:26 GMT

Wim,

the real difference between an initial erase, and not doing that, is in the effort that must be invested before you can HAVE a valid shadow.
With /erase, each member is erased (and only erased), AND MARKED AS SUCH. Forming a shadowset from erased members will avoid the need the synchronise ("merge") the members. And merging includes reading all members, comparing, and probably writing. All together, much more actions to be done than "just" erasing. And pre-erasing can be done at a more convenient time.
Bottom line: before being a valid shadowset at some time identicity HAS to be achieved.
Init /erase is just a way to achieve that in a more economic way.

Jan

Re: First shadow copy

Volker Halle — Thu, 12 Aug 2004 05:38:57 GMT

Wim,

the ERASE function is done by the 'local controller' and not with single IOs via MSCP. This explains, why it does not take much more time on the remote (MSCP-served) disk than on the local disk.

With V8.2, there will be INIT/ERASE=(INIT,DELETE), so you can specify whether you only want the disk to be erased or whether you only want to set ERASE_ON_DELETE or whether you want both.
With current versions, it's doing both.

A shadow-copy is a much more 'involved' operation requiring multiple reads and writes, this explains that it's much slower than an ERASE.

Volker.

Re: First shadow copy

Wim Van den Wyngaert — Thu, 12 Aug 2004 05:48:40 GMT

All,

If I understand correctly, the init must be done to make all disks the same (thus erase). But I just did an init without erase and that worked too. The volume was not marked "erase on delete" So, how did the shadowing know that both disks were ok ?

Volker,

If the init is done by the controller, why do I get substantial thruput during the operation (vpa) ?

Wim

Re: First shadow copy

Uwe Zessin — Thu, 12 Aug 2004 05:51:18 GMT

Wim,
of course you don't get a shadow copy on the first mount! And I didn't say so!

But if your now shadow set now incurs a merge - it will take longer, because it has to resolve the differences that won't be there if you had done a conventional shadow copy or use INITIALIZE/ERASE.

I don't know the code, but I guess that INITIALIZE/SHADOW just puts the same value into SCB$Q_GENERNUM. It does not 'know' if the disks are 'OK' - what would that mean to you anyway?

Re: First shadow copy

Wim Van den Wyngaert — Thu, 12 Aug 2004 06:42:40 GMT

Uwe,

OK the first merge will have some work.

But the help says :

Compaq strongly recommends that you use the /ERASE qualifier. By
using the /ERASE qualifier, no merge operation is required when
you create the shadow set with the MOUNT command.

"when you create the shadow set". So they say that a merge is done at creation. Which is not the case.

Wim

Re: First shadow copy

Wim Van den Wyngaert — Thu, 12 Aug 2004 06:50:38 GMT

When you add a shadow set, you can do init without /erase. Since the init writes the same data to both disks, it knowns that the data that is used is the same.

But suppose you allocate a file without initializing it. In that case, the 2 disks will have different data in the file. This should not give any problems because both are garbage. But suppose that a checksum is calculated based upon the garbage ? In that case you may get into problems.

So, this new feature may be dangerous ?

Wim

Re: First shadow copy

Uwe Zessin — Thu, 12 Aug 2004 06:52:26 GMT

You just have found another quirk in the documentation, congratulations ;-)

A merge would happen if the volume was marked for improper dismount, but that would defeat the purpose of using INITIALIZE/ERASE/SHADOW to save I/Os, right?

Re: First shadow copy

Volker Halle — Thu, 12 Aug 2004 06:58:25 GMT

Wim,

after INIT/SHAD/NOERASE the disks are 'the same' within the context of the file system.
Space outside the file system is most probably different. If you allocate a couple of blocks to a file and don't initialize them, those blocks contain 'garbage' - just as with a non-shadowed disk. Now with a shadowed disk, you could read 'different' garbage from the various shadowset members. But as long as you did not write to those blocks, what do you expect to read ?

Volker.

Re: First shadow copy

Wim Van den Wyngaert — Thu, 12 Aug 2004 07:01:42 GMT

Volker,

I agree. But in the pre 7.3 versions, it was impossible to read different data on the 2 members. So, behaviour is no longer the same.

Software should be requalified for this.

Wim
(going to stick with /erase just to be sure)

Re: First shadow copy

Volker Halle — Thu, 12 Aug 2004 07:14:17 GMT

Wim,

even with previous versions, you could still have the 'theoretical' case, where data was different on the 2 members: if something happened to your system(s) while a shadowing-IO was underway. The IO could have reached one disk, but no the other. The application would know, because it never got back a successful status from the write IO. That's what MERGE is used for, make sure all blocks are identical.

Volker.

Re: First shadow copy

Wim Van den Wyngaert — Thu, 12 Aug 2004 07:17:32 GMT

Volker,

yes but before 7.3 it was impossible for an application to read the different values. Now it is.

Wim