[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference vaxaxp::vmsnotes

Title:	VAX and Alpha VMS
Notice:	This is a new VMSnotes, please read note 2.1
Moderator:	VAXAXP::BERNARDO

Created:	Wed Jan 22 1997
Last Modified:	Fri Jun 06 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	703
Total number of notes:	3722

656.0. "Urgent help needed with volume shadowing and hsz50" by ARAFAT::ASUNDQVIST (Crashes for nothing, and Dumps for free) Wed May 28 1997 12:09

Hi,

I have an urgent question involving OpenVMS Alpha V7.1, Host Based Volume
Shadowing and HSZ50. THis note is entered in the HSZ40 and the VMS conferences.

first, What We want to achieve:

2 systems in 2 separate computer rooms, clustered via fddi.
1 system is a 4100 with a dual redundant hsz50 and RS28D's
1 system is a DEC 3000 M800 with locally attached disks (RZ28D)
We want to shadow the disks between the two systems, as well as locally
(ie 4 shadowset members)

How we would like to do it: Use mirroring in the HSZ for the 4100, and
create a 3 member HBVS set with 1 member being the HSZ mirrorset, the 
other 2 two locally attached rz28's on the 3800.


To verify if it works, I set up 1 RZ28 on the local scsi-bus on the 4100 and
1 on the HSZ50. When I tried to do a mount/shadow=(disk-on-hsz, disk-on-local)
I got a SYSTEM-F-INCSHAMEM, incompatible shadow set member error message. This
is regardless of whether the disk on the HSZ50 is set to TRANSPORTABLE or not
(and inited with nosave on the hsz50 as well).

If I do the same thing with two RZ28D's on the HSZ50 it works ok, as long as
both have the same characteristics (ie transportable or not does not matter,
as long as both disks are created equal...)

it also works to do a HBVS set with 2 HSZ50 mirror sets.

What I finally found was that the same RZ28, when in the HSZ50 had
a different geometry than when on the local scsi bus (I physically moved the
disk). on the HSZ50 it had 85 sectors/track, 13 (I don't remember to number)
tracks per cylinder and 3000-something total cylinders. when put on the local
scsi, it gets 86 sectors/track 13 (the same number) tracks/cylinder) and a
smaller number of total cylinders. The only thing that is constant is the total
number of blocks.


This raises a couple of questions.

1) Have I missed something?

2) Should it work?

3) Where is all this documented?
   I have looked in the shadowing SPD, the Shadowing manuals and in various
   other places and have found nothing. Am I really the first to beat my
   head against this wall.

4) Is there an alternative way of doing it? 


If it is impossible to solve, could someone PLEASE explain why it can't be
done (I already know that an rz28d has different geometries depending on
where you put it, so that's not an explanation - I want to know why)

Some time ago the phrasing in the shadowing documentation was change to say 
that  disks with similar geometries can be shadowed. This has led me to  make
the assumption that a hsz mirrorset consisting of rz28d's and 2 RZ28D's locally
attached can indeed be shadowed using HBVS.

HELP

Anders

T.R	Title	User	Personal Name	Date	Lines
656.1	Looks Like HSZ Question...	XDELTA::HOFFMAN	Steve, OpenVMS Engineering	`Wed May 28 1997 12:49`	16
	OpenVMS host-based volume shadowing requires disks of compatible (identical) geometry. Some storage controllers can shadow disks using the subset of the total device geometry that matches -- these controllers effectively "waste" the extra space above the "minimum" geometry "dimensions"... As for why the HSZ reports a different disk geometry, you'll want to take that up with the HSZ folks... You've already cross-posted this question in SSDEVO::HSZ40_PRODUCT, over in note 893.... That's probably the best spot for the specific question around why the geometry differs. You might also want to look at 505. over there, as well.
656.2	Home block placement requries same geometry	VMSSPT::JENKINS	Kevin M Jenkins VMS Support Engineering	`Thu May 29 1997 10:54`	7
	Put very simply, the geometry issue has to do with placement of the alternate home blocks. Since they are/were placed depending on geometry we could not allow different geometry disks in the same shadow set... Under certain failure conditions you can wind up with a disk that won't mount. Kevin
656.3	Sounds Like Good Area For Research...	XDELTA::HOFFMAN	Steve, OpenVMS Engineering	`Thu May 29 1997 11:14`	24
	: Put very simply, the geometry issue has to do with placement of : the alternate home blocks. Since they are/were placed depending : on geometry we could not allow different geometry disks in the : same shadow set... Under certain failure conditions you can wind : up with a disk that won't mount. We should probably rethink this in shadowing, akin to what was done with the disparate-geometry support in some controllers. The old "skewed" scheme for locating the alternate the home blocks doesn't necessarily even match some of the current schemes used for laying out the sectors in tracks across some disks... We might want to "ease" into this decision, by implementing a way where we can see if MOUNT ever really uses the alternate home blocks -- we may be solving a problem commonly found only on ancient disks, and long-since resolved by recent generations of better-quality disks, and by the "catastrophic" failures more common on current high-density disks. We may find we are seldom, if ever, going to the alternate home blocks -- either the primary is good, or the whole disk is shot. And if so, the whole design thus becomes anachronistic, and we can start to shadow disparate-geometry disks.
656.4	Home-Block Algorithm; Geometry-Independent Shadowing	XDELTA::HOFFMAN	Steve, OpenVMS Engineering	`Thu May 29 1997 14:42`	12
	MOUNT has been updated to use a geometry-independent home block algorithm. (This work predates the "Redhawk" compatibility kit, as Redhawk included some fixes for bugs in the new home-block algorithm.) There are also some folks here in OpenVMS that are looking at what would be involved in the (potential) implementation of geometry-independent host-based volume shadowing. If folks here with customers that believe this geometry-independent shadowing work should have its priority raised -- there are questions around much interest customers would have for this feature -- then I can provide the contact names here in OpenVMS engineering.
656.5		ARAFAT::ASUNDQVIST	Crashes for nothing, and Dumps for free	`Thu May 29 1997 18:52`	18
	> MOUNT has been updated to use a geometry-independent home block > algorithm. (This work predates the "Redhawk" compatibility kit, > as Redhawk included some fixes for bugs in the new home-block > algorithm.) There are also some folks here in OpenVMS that are > looking at what would be involved in the (potential) implementation > of geometry-independent host-based volume shadowing. > > If folks here with customers that believe this geometry-independent > shadowing work should have its priority raised -- there are questions > around much interest customers would have for this feature -- then I > can provide the contact names here in OpenVMS engineering. Please yes, give me some contacts. Anders
656.6	Its on the to do list - but when...?	EVMS::PERCIVAL	OpenVMS Cluster Engineering	`Fri May 30 1997 10:55`	16
	OpenVMS Cluster Engineering does have a project on its worklist - which will solve this type of problem, it is the Dissimilar Devices shadowing project. At present the priority of this project is superceded by other high profile projects, though recently there have been some moves to raise the priority such that it will be included in the next main OpenVMS release; those discussions are still in progress. I suggest that you contact Nick Carr on STAR::NCARR, as I know he is involved in this process. Regards, Ian
656.7	OpenVMS Shadowing Product Mgr (see note 7.*)	XDELTA::HOFFMAN	Steve, OpenVMS Engineering	`Fri May 30 1997 12:12`	2
	Alan Belanchik is the OpenVMS Shadowing Product Manager.
656.8	Belancik	HERON::BLOMBERG	Trapped inside the universe	`Fri May 30 1997 12:40`	1