HSG80 snapshot and VMS -- how to flush the disk?

[Verne Britton]

I am concerned that taking a snapshot of a mounted disk on a HSG80 (v8.8) will leave some data in cache (XQP or other places) on the OpenVMS host ... short of dismounting my disk clusterwide, how can I flush things on VMS to get a good snapshot?

I am running VMS 8.2 on three ES45s in a cluster ... I know I must shut down my Oracle instance before making the snapshot of the Oracle DB disks ...

would using the old trick ...

$OPEN/WRITE F1 [000000]INDEXF.SYS
$CLOSE F1

be enough? Or was the trick (to solve a different problem):

$OPEN/WRITE F1 [000000]QUOTA.SYS
$CLOSE F1

Also I am having troubles finding an example of using a undocumented XQP subfunction (well, I think it is undocumented) to flush things ... using the FIB$C_FLUSH_CACHE item I think ... found a VMS_SHARE file of Nick de Smith's code from Sept 1994 on C.O.V. but cannot UnShar it :-)

If dismounting the disks is the only practical way ...

p.s. is there an easy way to test any flushing technique ?


Verne

[Jon Pinkley]

Verne,

The best documentation I am aware of is in Chapter 7 of the VMS Volume Shadowing manual on pages 123-126. This discusses the requirements to ensure data consistency when removing a shadow set member, and the same applies to HSG80, EVA or other controller based "snapshots".

http://h71000.www7.hp.com/doc/732final/documentation/pdf/aa-pvxmj-te.pdf

The XQP is currently writethrough, so that cache should not affect what is written to disk. RMS deferred writes are the bigger problem. This is all discussed in the above reference.

Getting your applications to flush the data is the hard thing, and usually shutting them down is the only guaranteed way to get them to write their buffers to disk.

Good luck,

Jon

[Jon Pinkley]

I wrote "The XQP is currently writethrough, so that cache should not affect what is written to disk."

What I meant was "The XFC", i.e. the file cache.

I do believe any changes that are done to disk by the XQP, i.e. updating file headers, etc. are also "writethrough" to disk. Historically, the VMS file system is rather conservative with respect to being careful to leave the file system metadata in a consistent state. There are fewer safeguards for the contents of the files, i.e. you can have RMS buffer things up with deferred writes to gain performance, at the expense of consistency in the case of a crash or loss of power.

Jon

[Richard W Hunt]

I don't have a solution for you, but I have observed a similar issue when you are using third-party products for your storage area network. EMC2 products have the same issue, for example.

I've been searching for a solution since 2002 and have yet to find anything better than killing all processes having anything open on the disk and doing a quick dismount and remount. But that solution stinks and is very disruptive.

[Jim_McKinney]

> Nick de Smith's code from Sept 1994

I incorporated that code of Nick's into a utility that I once wrote. Maybe you can use the attached subroutine (which may be exactly what Nick posted or might have evolved - can't recall) - however, as others have noted already there are several locations where data is cached and this is only a piece of them.