What is the Disk Geometry on DMX and How do we Enable it ?

There is a whole section in SolEnab 6.5 manuals .. you need S.E. 6.5 and a skilled Solaris Administrator
I have patience .. but no deep knowledge of Solaris

Have a look at page 65, Solutions Enabler Symmetrix Array Controls CLI manuals, P/N 300-002-940 REV A05 .. and enjoy !!

Found the below points - just for sharing...

Flexible device geometry (For Solaris OS ) :-
Flexible device geometry improves interoperability when migrating data between DMX-3 or DMX-4 and older Symmetrix systems.
When the Symmetrix DMX-3 was introduced, the disk geometry presented to the host by the disk array changed. The number of sectors per track was doubled to 128, which also led to a doubling of the cylinder size.

In the Sun Solaris operating system, disk geometry, disk size, manufacturer ID, and the partition table are stored in the label in
sector 0 of the disk. The label is written to the disk using the format utility, which makes a device usable to the OS. When a Solaris device
is opened for I/O activity, the label is written to host cache and the SCSI driver uses the partition information to translate relative
partition addresses to device absolute logical block addresses.
MX-3 Hardware
The difference between disk geometries will not cause issues in most scenarios. However, there are three pieces of information contained in the disk label that, if modified, can cause a new label to be written by the operating system. If disk geometry, manufacturer ID, or the size of the disk drive change, format will write a new label if ¿auto
configure¿ is run from the format> type menu, followed by label.

When a device is migrated to a DMX-4 or DMX-3 using a product that produces a track-by-track copy of the source device on the target device (SRDF, RecoverPoint, or Open Replicator for example), the entire device is migrated including the VTOC label. When this occurs between devices with heterogeneous disk geometries, there will be a difference between the disk geometry written in the label on the target (which was copied from the source) and the disk geometry that is presented to the target host by the DMX-4 or DMX-3.

If the device is re-labeled, there may be potential issues with data availability. This is because Solaris reserves two cylinders from every device for
use by the operating system. DMX-4 and DMX-3 cylinders are twice as large as cylinders from previous generation Symmetrix disk
arrays, meaning that the operating system will overwrite the last 1920 sectors (i.e 30 tracks i.e 2 cyl ) of the user data area with an area reserved for operating
system use. It should be noted that, regardless of a difference in geometry between the label and the actual disk, no issue will be seen
if the disk is not re-labeled by the user.

This potential issue has been resolved with the introduction of Flexible Device Geometry. To alleviate any potential for corruption, two features have been added to Symmetrix Enginuity. A bin file setting has been included that allows the DMX-3 and DMX-4 to present an external device geometry for all Symmetrix devices that is identical to the device geometry of earlier Symmetrix arrays. Functionality has also been added to Enginuity that allows alternate disk geometry to be presented on a device by device basis.

Note: Contact your EMC Customer Engineer to determine if this feature should be enabled on your Symmetrix DMX system .

Bhat ...thank you for sharing your findings. I will be migrating a couple of Solaris 8/9 boxes to DMX3 from DMX2000 so this could be an issue for me. So reading from the article, this feature is not enabled by default ..can we enable device-by-device option via symlci ?

It seems we have that option if you got 73 Code. If 71 & 72, Then it is for the entire box .I don't have the definite procedure on how it is done because the activity was carried out by EMC guys.

Hello All,

Yes, the advice posted above is precisely correct. However I would like to expand on this Symmetrix Configuration feature just a little further....

The "Flexible Device Geometry" or "Spoof Geometry" feature can be enabled in the Symmetrix bin file at 577x. This allows the native 64kb track size of the DMX-3/4 to be presented as the older 32kb track size of the DMX.

This requirement is ONLY for Solaris. This requirement is also ONLY for volumes migrated from the DMX to DMX-3/4 (where the Solaris written volume label copied from the DMX won't match the physical disk geometry currently reported by the 577x microcode).

You can refer to solution emc171629 for a brief explanation of the issue that "Flexible Geometry" addresses (note that the powerformat command can also be used as an alternative method of correcting any Solaris label mismatch issues).

In any case, the need (or otherwise) of setting the "Flexible Disk Geometry" bin flag needs to be discussed with your local EMC Support Representative (since changing this bin flag is disruptive).

As Bhat has also already noted at Enginuity 5773 you don't need to set the "Flexible Disk Geometry" bin flag. Solutions Enabler 6.5 (at 5773) can set this flag at the logical volume level - eliminating the need for an EMC CE bin file change OR for the use of the powerformat command.

Best Regards,
Michael.

Man you choose the wrong thread .. no points for you here !!

Michael,

if i have an existing DMX3 running 71 and i need to migrate a couple of Sun boxes to it, since i am not at the code level where i can upgrade to 73 my only option would be to enable it in the bin. How will this flag affect hosts that are currently using storage of this DMX3?

Thanks

Hi Dynamox,

Quick answer - NO affect whatsoever on non-Solaris hosts.

But just to clarify (for anyone else reading this thread) - the requirement is straightforward - we need to ensure that the part of the Solaris volume label displaying the physical device geometry (written when a volume is formatted by the host) matches the current physical geometry reported by the Symmetrix storage device.

So any EMC "data migration" (SRDF or Open Replicator) that copies the original Solaris device label to a new storage platform is potentially at "risk" (for example, if auto configure is run and the Solaris volume is re-labeled).

"The host command PRTVTOC will display the device geometry. This will match the geometry that the source array presented when the source device was labeled. So regardless of whether the source array was a Symm5, CLARiiON, HDS, or IBM, the geometry written to the source by that array prior to the migration will be the geometry in the label that exists on the DMX-3 target device."

Now this is where it can be complicated.

What we need to do eliminate this discrepancy by EITHER ensuring the new storage platform reports the old geometry (to match the existing label) OR we update the Solaris volume label.

The Solaris label can be updated online using the previously mentioned powerformat command (in this case the old label would then reflect the new / currently reported device geometry). This can be performed AFTER the successful data migration.

The other option is to change the "Flexible Geometry" flag on the DMX-3/4 BEFORE the data migration so that the new storage reflects the old 32Kb track geometry of the DMX.

In this case please be aware that this will create a problem if Solaris volumes have already been created / labeled on the DMX-3/4 using the DMX-3/4 native 64kb track geometry (in this situation the label on these existing volumes would then need to be corrected).

Yes, you can have the "Flexible Device Geometry" bin flag enabled by the local CE. This requires that ALL Open Systems host adapters be taken OFFLINE (while the resulting flag change will only affect Solaris hosts this is an EMC Engineering safety precaution to avoid any possible host impact).

So you can see why changing the reported device geometry at the individual logical volume level via the SYMCLI (Enginuity 5773 required) is a MUCH more elegant and desirable solution.....

Best Regards,
Michael.

ouch !!! ...i think i already know the answer to my problem ..powerformat here i come .

Michael ..so powerformat needs to be run right after the device has been either SRDFed/OpenReplicated to DMX3 but before the volume group has been activated ? Any caveats if the system is using Veritas versus native volume manager ? I am not familiar with powerformat ..do you run it against PowerPath pseudo device or against the native device CxTxDxSx ? I would think PowerPath device but wanted to double check.

Thank you so much for your help

Hi Dynamox,

Your welcome, I thought I should make sure all the available options clear (which is why I posted to the thread ).

O.K. You DO need to speak to an EMC Solution Support Representative about powerformat (or look for other more informed opinions on the forum) I am not qualified to answer your question. However the way that powerformat was presented to me:

It looks like powerformat can be run against raw devices whose partitioned devices contain mounted file systems; ie, a file system on /dev/dsk/c4t30d2s2 is mounted on /fs1 and powerformat can be run against the raw device /dev/rdsk/c4t30d2s2 without causing problems for the file system. That said, I always recommend that these types of commands be run when file systems are not mounted.

Best Regards,
Michael.

Hi Guys...
Real Busy for last one Week...
Thanks Michael for adding to this Post, things mentioned by you were very informative and did clear few doubts that i had. We are going through a migration process... Lets see if i face any issue with this.

Message was edited by:
Bhat