First shadow copy

[Wim Van den Wyngaert]

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

[Wim Van den Wyngaert]

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

[Jan van den Ende]

Wim,

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

Jan

[Wim Van den Wyngaert]

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

Wim

[Uwe Zessin]

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

[Wim Van den Wyngaert]

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

[Antoniov.]

Uwe,
SET VOL /NOERASE avoid erase on delete.

Antonio Vigliotti

[Uwe Zessin]

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?

[Wim Van den Wyngaert]

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

[Jan van den Ende]

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

[Volker Halle]

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.

[Wim Van den Wyngaert]

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

[Uwe Zessin]

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?

[Wim Van den Wyngaert]

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

[Wim Van den Wyngaert]

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

[Uwe Zessin]

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?

[Volker Halle]

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.

[Wim Van den Wyngaert]

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)

[Volker Halle]

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.

[Wim Van den Wyngaert]

Volker,

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

Wim

[Antoniov.]

Wim,
starting from V7.3 HP added some feature for volume shadowing.
SET SHADOW
SHOW SHADOW
ANALYZE/DISK/SHADOW
see here
http://h71000.www7.hp.com/doc/732FINAL/aa-rv8xa-te/aa-rv8xa-te.HTML
It seems, now, you can create shadow with different size disks.

Antonio Vigliotti

[Volker Halle]

Wim,

regarding ERASE via MSCP:

I've just tested this: you see no MONI MSCP traffic on the remote node, where the disk is connected to. MONI SCS shows nothing. MONI DISK shows nothing (as the disk is not mounted), yet the Operations completed count increases.

So it depends where VPA is getting it's data from. And erasing 36GB in 35 minutes via MSCP and a network would require a FAST network indeed.

Volker.

[Jan van den Ende]

Wim,

pre-7.3, just as now, IF data is on a shadow set , any application only 'knows' that the info is at VBN=nnn on device Dxxx. In case of shadow sets, that device happens to be DSAmmm. Only the 'device' driver SYS$SHDRIVER 'knows' about members, and potential non-identicity. For READs, a copy-target is ignored, and for merging shadow-sets, 'behind the fence' members ARE identical, so any read wil do, 'before the fence', each member is read, results compared, and the members MADE equal before the data is passed to the applic.
No difference here eigther.
Not-yet allocated space to-be-written to is written identical anyway, so, irrespective of before-write, after-write THOSE blocks are also identical.

Incidentally, for DUMPFILE.SYS this is NOT true! Dump-info is written ONLY to the master-member, but then, programs to access SYSDUMP.DMP know that too, as does SYS$SHDRIVER.

Jan

[Wim Van den Wyngaert]

Antonio : it is from 7.3-2 ... I am on 7.3

[Wim Van den Wyngaert]

Jan,

You are absolutely right for pre 7.3.

But if I now initialize a sybase file, the disks of the shadow sets do not contain the same info because they were not erased. So, depending on which disk you use, you get other data.

Since no merge is done after the mount, no compare is done. You simply get different data depending on which disk you use.

This is very difficult to test because you need an application that uses the uninitialized data.

In my opnion a bug. A merge should be done when /noerase is used.

Wim