Conference ssdevo::hsj40_product

Martin:

What versions of HSOF were the 3 RZ28 stripeset and the 6 RZ28 striped
mirrorset created under? Were they different?

	A mirrorset with 2 RZ28D has the same geometry as a single/normal
	RZ28D, but as soon as we bind them into stripesets, the geometry
	changes. 
	This is sad, because the only way now to go for striped mirrorsets
	is via backup.

	It looks for me that we missed something when we changed the 
	geometry of the mirrorsets. (from V2.5 to V2.7 HSOF)
	
	Or did i miss soemthing ?? Is there a technical explanation for this
	behaviour ?

The underlying problem here is due to an unfortunate bug in V2.5.
We tried to correct the problem in V2.7, but backward compatibility
issues for units already initialized limited the amount of change we could
make. The result is an imperfect compromise.

Geometries for all storagesets are "fictitious", and a constraint imposed by
earlier versions of VMS is that certain fields in the geometry not exceed
certain values. Since binding members into stripesets "n-tuples" the values
in some parameters, the controller sometimes has to "fudge" the geometry into
an acceptable reportable result.

If both stripesets are attached to the *same* model HSZ running the same
versions of the firmware, and you are running VMS 6.2 or later, one possible
way out of the bind is to convert the 3 member simple stripeset into a
3 way striped mirrorset with one member per mirrorset. That should result in
the same geometry as if there were 2 members present - it is the "striped
mirrorset" attribute that determines geometry algorithm, not the number of
members actually present in the mirrorsets. By making both sides into "striped
mirrorsets", even if one only has half the disks, we force both sides to use
the same geometry calculation algorithm. You can use the MIRROR command to 
effect this change to the 3 member stripeset.

This can be risky though, so I would not recommend it for critical data. The
geometry will change when you issue the MIRROR command, so the unit should not
be online. Make sure you have a full backup of the unit first (just in case),
make sure the version of VMS is 6.2 or later, and make sure both controllers
are running the same version of firmware.

All that said, given that you have to take a full backup anyway, just restoring
to a new unit of the proper construction is probably the safest way to go.

Bob

	Hello Bob,

	thanks a bunch for you reply.

	The customers cluster is running VMS V6.2-1H3 and latest
	patches (ALPSHAD05 and ALPDRIV04).

	The mirrored stripeset was built with V5.0-2. The results can
	"easy" ( who has six drives ?) beeing reproduced. 
	Just take 6 drives of the same type and build a stripeset of 
	2 drives and a striped mirrorset of 4 drives and you'll see, 
	that the geometry is different. 
	
	Thats also what the customer did.
	He had an existing stripeset amd wanted to add a striped mirrorset
	into the existing shadowset because of performance reasons. 
	We considered this as an easy way to check for a perfomance increase.	
	Now we have a lot more to do...

	Because this did not work, they did the above test with the 6 drives
	with the resluts of the geometry differences.
	I really hope i can rely on the customers words that he did it
	the way i explained. Unfortunately, i dont have six drives of the
	same type to verify the customers experience. 	

	Your workarround sound good, but as you already told, is also a bit
	risky and database has to be taken down anyway. 
	The data on this disks in very hot.... They are their life ;-).
	
	Cheers,

	Martin	
	
	
	
	
    

    Maybe I'm just dumb but if you generate a mirror set of two drives you
    put meta-data on each drive to reflect this status. Then you make a
    stripeset out of the two mirror sets so you add more meta-data to
    reflect this status. The two drives that aren't mirrored but striped have
    their stripeset meta-data but no mirroring meta-data so must have more
    blocks free than the other drives as they have two sets of meta-data.
    How can they be the same? Or did I miss something?
    
    Keith

Stripesets do not add blocks of metadata on top of devices or mirrorsets.
That is not the reason for the geometry issues.

	Hello Bob,

	I did some more further investigation of this issue.

	It came to my mind, that i also can take two drives and create
	single member mirrorsets.

	I took 2 RZ28-VA from our stock and tried the following on our
	VAX6540, VMS V7.1 and HSJ40 with V2.7-1.

	- Created stripeset and showed geometry 
	- Created single member mirrorsets and striped them 
		-> both the same geometry ... all o.k.

	Then i called the customer and logged into his system
	A8400, VMS V6.2-1H3 and HSJ50 with V5.0-2 and HSJ40 with V2.7-1.
	
	on one of his HSJ50 with V5.0-2:	  

	- Created stripeset and showed geometry
	- Created single member mirrorsets and striped them 
		-> still both of different geometry

	on one of his HSJ40 with V2.7-1:
	- Created stripeset and showed geometry
	- Created single member mirrorsets and striped them
		-> both of same geometry ... all o.k.

	It seems, that the striped mirrorsets on the HSJ50 have different, 
    	"not to fortunate" geometry than the HSJ40's.
	Then i did what you advised... Because of the disk i wanted to add
	where all new/empty, i created on the HSJ50 with V5.0-2 a stripeset
	with 3 members and created with the mirror command the mirrorsets.
	It worked perfect. 
    	I wouldn't do it with the customers hot data but here, but here 
        this was a good workarround.
	He can now add the striped mirrorset to the existing shadowset. 
	After that remove the other members and create the same way a new
	striped mirrorset and add it again into the shadowset...
    
	Martin

    

Thanks for the extra clarification.

It appears that something changed between V2.7 (the last release with which
I am familiar regarding the geometry algorithms) and V5.0, and that we need
to pursue it further.

Bob
.

The geoometry issues are still alive.

I have a customer that has hsj40 and hsj50 in the same cluster.

Create a 4 member stripe on the hsj40 (all RZ28D) yields: ~3022 Cylinders

create a 4 member stripe on the hsj50 (ALL RZ28) yields: ~8072 Cylinders


This does not facilitate Host based shadowing...

RE: .7

Our testing has not revealed geometry changes for true "stripesets" between
HSJ40 and HSJ50 code.

If the "stripesets" are actually 0+1 sets, this is believeable. To work around
the problem, delete the HSJ50 stripeset and re-add it using the following
commands:

	ADD STRIPE <stripename> <disk1> <disk2> <disk3> <disk4>
	INIT <stripename>
	ADD UNIT <unit> <stripename>
	MIRROR <disk1> <mirror1>
	MIRROR <disk2> <mirror2>
	MIRROR <disk3> <mirror3>
	MIRROR <disk4> <mirror4>

There was a problem introduced in HSOF V30/V50 where 0+1 sets created using 
the following sequence of commands:

	ADD MIRROR <mirror1> <disk1a> <disk1b>
	ADD MIRROR <mirror2> <disk2a> <disk2b>
	ADD MIRROR <mirror3> <disk3a> <disk3b>
	ADD MIRROR <mirror4> <disk4a> <disk4b>
	ADD STRIPE <stripe1> <mirror1> <mirror2> <mirror3> <mirror4>
	INIT <stripe1>
	ADD UNIT <unit> <stripe1>

gave a different geometry than straight stripesets or 0+1 sets initialized 
with the top sequence of commands. The geometry for these 0+1 sets is the
same as was produced in V2.5.

This will be fixed in a future release of the software.