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

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)

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 )

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

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        -       -                     -      -
       }
 
-------------------------------------------------------------------------------

5671 isn't that bad ..

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

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.

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

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.

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

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.

Million dollar question : Why did SE allow me to run the script ??

Also,Anybody noticed my 1st question ?

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.

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