Problems on Meta Expansion - Disk Extension

Question

-I started a meta expansion script to expand an existing meta of 'striped' and the expansion on Disk completed.But while using diskpart,The command 'extend' has taken more than 2 hours but yet to complete.

Is it normal to take a long time, I dont want to close or do and end task as I am risking Very Imp Data

-The 2nd Problem is that,I added a 17 GB device to a existing meta of 8.5GB meta members.Now in disk mgmt I see an unallocated space of 8.5Gb instead of 17 GB ! Where is the rest 8.5 GB!

---------------------------------------------------------------------------------
Meta Device Members (8) :
{
----------------------------------------------------------------------
BCV DATA RDF DATA
---------------------------- --------------------------
Sym Cap Std Inv BCV Inv Pair R1 Inv R2 Inv Pair
Dev (MB) Tracks Tracks State Tracks Tracks State
----------------------------------------------------------------------
0D50 8714 - - N/A - - N/A
0D51 8714 - - N/A - - N/A
0D52 8714 - - N/A - - N/A
0D53 8714 - - N/A - - N/A
0D54 8714 - - N/A - - N/A
0D55 8714 - - N/A - - N/A
0D56 8714 - - N/A - - N/A
--> 10A7 17428 - - N/A - - N/A
----------------------------------------------------------------------
69713 - - - -
}

--------------------------------------------------------------------

MarcT2 · Answer

Many years ago I encountered a striped meta built with different sized meta members on a Symm 5.0. The overall size becomes (smallest member * member count) and the rest of the space is wasted.

The code really should check for this and prevent you doing it, but maybe it doesn't?

The bad news is that you will have to back up the data and dissolve the meta to recover the wasted space.

M

xe2sdc · Answer

AFAIK all meta members must have same size .. So if metahead is 8.5 gb, you can add only 8.5 gb devices.

Maybe you have issues with symcli command reporting wrong sizes ??

Can you please show output of following commands ??

hunter.root./ $ grep 32K /var/symapi/config/options
# Parameter:                         SYMAPI_TRACK_SIZE_32K_COMPATIBLE
#                                               32KB track size
#SYMAPI_TRACK_SIZE_32K_COMPATIBLE  = ENABLE
hunter.root./ $ symcli
 
 
Symmetrix Command Line Interface (SYMCLI) Version V6.5.0.0 (Edit Level: 872)
built with SYMAPI Version V6.5.0.0 (Edit Level: 872)

amrith · Answer

Thanks Stef for editing my SID

Hers is the symcli version:

Symmetrix Command Line Interface (SYMCLI) Version V6.5.1.0 (Edit Level: 883)
built with SYMAPI Version V6.5.1.0 (Edit Level: 883)

What is 32K compatibility state ?

( and of course how to find out )

amrith · Answer

S Y M M E T R I X

Mcode Cache Num Phys Num Symm
SymmID Attachment Model Version Size (MB) Devices Devices

000287890xxx Local 3000-M2 5671 131072 5 5225

on a 17 GB hypers, I wasn't able to add 8.5 Gb hypers as symconfigure blamed me for adding devices who are smaller than the smallest hyper.

Hence I tried to add 17Gb to 8.5 hypers,Of course it didnt have any problems in SL but diskmgmt seem to dont recognise.

Message was edited by:
Stefano Del Corno

MarcT2 · Answer

I know - I was looking at the original post. The formatting is a bit skewed, but see below, device 10A7:

-------------------------------------------------------------------------------
   Meta Device Members (8)  :
       {
       ----------------------------------------------------------------------
                              BCV  DATA                    RDF  DATA
                     ----------------------------  --------------------------
       Sym    Cap    Std Inv BCV Inv Pair          R1 Inv R2 Inv Pair
       Dev    (MB)   Tracks  Tracks  State         Tracks Tracks State
       ----------------------------------------------------------------------
       0D50   8714        -       -  N/A                -      - N/A
       0D51   8714        -       -  N/A                -      - N/A
       0D52   8714        -       -  N/A                -      - N/A
       0D53   8714        -       -  N/A                -      - N/A
       0D54   8714        -       -  N/A                -      - N/A
       0D55   8714        -       -  N/A                -      - N/A
       0D56   8714        -       -  N/A                -      - N/A
  -->  10A7  17428        -       -  N/A                -      - N/A
       ----------------------------------------------------------------------
             69713        -       -                     -      -
       }
 
-------------------------------------------------------------------------------

xe2sdc · Answer

5671 isn't that bad ..

xe2sdc · Answer

You are welcome ..

Old DMX have 32K tracks .. new DMX3/4 have 64K tracks. Your box is a DMX3000 (thus using 32K tracks) however Solution Enabler 6.5 changed its defaults and maybe there is something strange going on ....

hunter.root./ $ grep 32K /var/symapi/config/options
# Parameter:                         SYMAPI_TRACK_SIZE_32K_COMPATIBLE
#                                               32KB track size
#SYMAPI_TRACK_SIZE_32K_COMPATIBLE  = ENABLE

xe2sdc · Answer

So I'd better ask amrith to shou also the output of following command:

desiree.root./ $ symcfg list | grep xxxx
    00029010xxxx Local       DMX4-24   5773      196608        40      4817
desiree.root./ $

where xxx is the SID of the storage that's showing this strange behaviour.

xe2sdc · Answer

Marc unfortunatly I can't dial customer boxes or retrive their binfile .. If you need box SN contact me offline. ThX.

xe2sdc · Answer

Amrith can you please show symcli version and 32K compatibility state ??IMHO your very last message points toward a symcli problem rather then a code problem.

MarcT2 · Answer

I don't think it's a 32k track compatability issue - you can clearly see in the "symdev show" output that the final meta member is larger than the others.

SYMCLI just calls the expand striped meta Symmwin (Enginuity) script. IMHO this script should check for larger members being added to a meta, and either issue a warning or just fail.

To address the original problem - I suspect the 8.5GB hypers you were trying to add were either not the same cylinder size as the existing meta members (ie slightly too small), or were a different RAID protection type, or possibly on different capacity/performance drives. The SYMCLI logs should give you some clue.

M

xe2sdc · Answer

Amrith unfortunatly I don't have experience with diskpart .. So I can't say if it's running fine or it's wasting time.

Why did S.E. allowed you to run the script ?? It's a nice question and we are forwarding it at the appropriate guy

.. At least I hope he is the appropriate guy.

amrith · Answer

Million dollar question : Why did SE allow me to run the script ?? Also,Anybody noticed my 1st question ?

xe2sdc · Answer

ThX Marc .. I've seen last device and its bigger size .. however I'm still unsure if recent codes allows expanding a striped meta with larger members, thus wasting space. I still prefer to think it's a symcli issue, at least unless I see a volume map showing the strange meta with its members .. However I'll dig a little in primus.

bodnarg · Answer

There is a known problem with version 72 microcode that striped meta expansion scripts will fail to complete and need manual intervention by EMC to complete. Not sure when this problem was introduced specifically, but I know the latest 72 microcode does not fix it as we are still waiting on an ETA for the fix.

My guess is this may be your problem with the hang - however as to the problem with why it allowed you to use a larger device not sure - that is definitely an symconfigure bug!

I think with concatenated metas you can use larger devices and see the storage, but makes sense this would not work for stripes. The software should protect you from wasting space - wait a minute - maybe EMC has a vested interest in allowing you to waste disk space

Symmetrix

Problems on Meta Expansion - Disk Extension

Was this post helpful?