what is the "bin file" in symmetrix enviroment ?

bin file is a configuration file that contains configuration about your array, disk layout, settings ..etc. It is edited by application Symmwin that resides on the service laptop/server in the array cabinet itself. symapi_db.bin is a file created by solution enabler that contains information about your environment.

thank you for answer the question. could you please
clarify are there exist any relationship
or inter-dependency's between the two: the "bin file" and symapi_db.bin?

when EMC CE making change to the array , like create hypers, that change is reflected in the "bin file", is that the only purpose of bin file or more? what is
the typical change that may involve change the bin file?

when user make other change through SYMCLI (logical change, such as
create metas, bind to FA etc), that change is reflected in the symapi_db.bin or VCMDB, is that accurate statement?

if I need change two-way mirror to un-protected ( say to free up some space,)
does a change in bin file needed?

Thank again.


Thanks.

sort of, bin file contains configuration about symmetrix array ..while symapi_db contains information about one or more symmetrix arrays in the environment...even the ones connected via SRDF links. Symapi_db resides locally on a host that has solutions enabler installed, where bin file resides on the service laptop/server and can be edited by CE and lab via symmwin application. Here is definition of symapi_db.bin

A SYMAPI configuration database (.bin) file, which is stored on the host system, contains the
physical configuration information of SCSI devices and Symmetrix parameters that define
your entire storage complex. More than one configuration database file may be required to
support your operational needs.
The SYMAPI configuration database is sometimes referred to as the host configuration
database, SYMAPI database (because of how the file is named), or the Symmetrix database
file. All of these names are referring to the same configuration database file, symapi_db.bin

when CE makes changes they most likely use symmwin, these changes typically can not be done via symcli (VTOC, disk group creation ..etc). When you and i make changes via symcli we are making changes to the bin file as well. Solutions enabler has come a long way where so many config changes that could only be done via symmwin now can be done via symcli.



when you create metas, mapping ..you make changes in the bin file. Masking makes changes in the VCMDB. When you run symcfg discover command ..that updates symapi_db with information about your symmetrix environment ..but remember symapi_db is local to that particular host where SE is installed. So if you were to create device groups local to that host ..they would update the symapi_db.bin file.




you can do it via symcli, although i don't think symcli will allow you to remove protection from a 2-way mirror STD device ..but you can do it with 2-way mirror BCV without problems ... and yes ..that would be a bin file change performed via symcli.


i am sure Stefano can add to it ..he's got great analogies to explain this

Hi Dynamox and Jasonj .. let me jump in for some analogies .. and to pinpoint some things that can be explained in a different way



Let's start with an analogy .. Think to the binfile like a precious book .. You have different precious books in different libraries (a different binfile in every box). You are not allowed to take those precious books with you. But you can take copies of them at home while doing your homeworks.
The collection of copies you have at your home looks like the symapi_db.bin that you have in your host.

Now imagine someone changes a page in the original precious book (hmmmm I know it's not a great analogy, but please keep on reading :D). Your copy will not change "automagically". You have to go again to the library and ask for a new copy of the same book. That's what you do when you issue "symcfg discover" and update your symapi_db.bin ...



The "binfile" is actually the configuration of your storage.
Each and every aspect of your box is defined in the binfile.
How are the ports of your frontend configured ??
How are the volumes layed on the disks ??
How are your volumes protected ??
How are your metavolumes formed ??
How are your volumes mapped on the frontend ??
Are there relationship with other boxes (SRDF) ??
The list of questions that can be answered via a query to the binfile is almost endless. You can know how much cache you have, how many boards are in your box.

Maybe it's easier to understand what isn't in the binfile ...
In short, the things that are outside the binfile are all the statistics, all the counters that describe the "dynamic" behaviour of your box, and not the "static" configuration. If you establish a STD with a BCV, the relation between the volumes is dynamic, just like the number of tracks that needs to be copied. A clone session is dynamic, just like a snap session. There are also other "noticeable" things that lives outside the binfile. I'm thinking at MASKING (the VCMDB) and dynamic RDF. Yes dynamic RDF is a PROPERTY statically configured in the binfile BUT a DYNAMIC relation mantained in cache and elsewhere (not in the binfile).

When you change something "dynamic" (look above) your binfile will NOT change. When you change something "static" your binfile WILL change.



While the "binfile" is cached on each and every host running symcli, the VCMDB is always accessed directly from the storage, without caching.

When you issue a symconfigure command to form your metas, the symconfigure command will run (in recent Solution Enabler versions) an automatic update of the symapi_db.bin ONLY on the host where symconfigure is running.
All the other hosts will NOT be updated 'till you issue a "symcfg discover" or the daemons running on them note that the config-checksum changed and forces a "discover".

In other words .. when you issue a command that changes the binfile, the command itself will update your LOCAL db. All other symapi_db.bin will be stale 'till something or someone will trigger a discover.

You can verify quickly that forming a meta will be reflected immediatly in your local symcli while the same meta can not be seen immediatly from another host.

It takes some time to know that you changed the precious book and that all other hosts needs to go again to the library to get their new copy



Unfortunatly you CAN do this change .. but it will NEVER give you more space ..
You start with a 2-way-mir device (i.e. symdev 03F4) and ask to convert to "unprotected" .. This will give you TWO unprotected device .. the good old 03F4 and a brand new 0987 device. A brand new different (and unprotected) device that will go to the end of the list of the devices.

You can -later- delete the unneeded 0987 device and reclaim your space. At least two different changes in the binfile.. Not too bad, don't you think ??

Hope not to bore you ... Bye

wow ..i would not think EMC would allow to remove protection from a STD device ..that's asking for trouble ..unless you really really really want to do it. I have been too chicken to even attempt that

Eheheh .. I know someone that hadn't been as chicken as you .. and is still asking EMC to fix the damage

BTW if you have a DMX (and ONLY if you have a DMX or better) you can try the following steps ..

1) pick a 2-Way-Mir device and find where in the backend it is located
2) use symconfigure to obtain 2 Unprotected volumes (convert xxx to unprotected)
3) use symconfigure to delete the "brand new" volume (obtained at step 2)
4) use symconfigure to protect again your original volume (convert xxx to 2-way-mir)
5) check where in the backend it si locadet NOW

our CE tries to keep our arrays up to day so ... I am waiting for functionality where i can say ..create a hyper ..in this particular disk group, on these particular spindles, on outer edge of the drives ..remove the rule where hypers with higher addresses can not be above hypers with lower addresses. Here is what i am talking about:

  Hypers (22):
  {
  #   Vol  Emulation        Dev  Type          Mirror Status         Cap(MB)
  --- ---- ---------------- ---- ------------- ------ -------------- --------
    1  748 CELERRA_FBA      1326 RAID-5          1    Ready             19654
    2  749 CELERRA_FBA      132A RAID-5          1    Ready             19654
    3  750 CELERRA_FBA      132E RAID-5          1    Ready             19654
    4  751 CELERRA_FBA      1332 RAID-5          1    Ready             19654
    5  752 CELERRA_FBA      1336 RAID-5          1    Ready             19654
    6  753 CELERRA_FBA      133A RAID-5          1    Ready             19654
    7  754 CELERRA_FBA      133E RAID-5          1    Ready             19654
    8  755 CELERRA_FBA      1342 RAID-5          1    Ready             19654
    9  756 CELERRA_FBA      1346 RAID-5          1    Ready             19654
   10  757 CELERRA_FBA      134A RAID-5          1    Ready             19654
   11  758 CELERRA_FBA      134E RAID-5          1    Ready             19654
   12  759 CELERRA_FBA      1352 RAID-5          1    Ready             19654
   13  760 CELERRA_FBA      1356 RAID-5          1    Ready             19654
   14  761 CELERRA_FBA      135A RAID-5          1    Ready             19654
   15  762 CELERRA_FBA      135E RAID-5          1    Ready             19654
   16  763 CELERRA_FBA      1362 RAID-5          1    Ready             19654
   17  764 CELERRA_FBA      1366 RAID-5          1    Ready             19654
   18  765 CELERRA_FBA      136A RAID-5          1    Ready             19654
   19  766 CELERRA_FBA      136E RAID-5          1    Ready             19654
   20  767 CELERRA_FBA      1372 RAID-5          1    Ready             19654
   21  768 CELERRA_FBA      1376 RAID-5          1    Ready             19654
   22  769 CELERRA_FBA      137A RAID-5          1    Ready             19654
  }

let's say i want to create a new hyper that's going to be twice the size of device 1326. So let's say i delete hyper 1326 and 132A ...and create new hyper. Right now i have no control where the new hyper is going to end up, it may end up on entirely different set of spindles. If the new hyper gets address of 137B ...there is no way it's going to be on the top of this list hence on outer edge of my spindle. Gimme more control EMC

ps. Jason..sorry if i hijacked your thread

is it going to put it on a different spindle ? so probably different DA ?

Generally speaking if the original binfile has been crafted with the same code-level as the code-level running in the box right now, the spindle MUST be the same as before .. Same code = same rules = same spindles .. If you had code upgrades since the original install the second copy of your volume MAY be allocated elsewhere .. I underline MAY even if it's november

I also contributed a lot in hijacking this thread .. and it happens quite often when answering Mr Dynamox posts

You are right .. I also feel the lack of control on where the hypers are layed out ..

But if giving a customer the power to remove the protection on its volumes is something like a gun, giving him/her the power to choose where the data will go can even be worst in someone's mind ..

I think that customers may put a RFE (request for enhancement) and ask for this control

-s-

PS don't play too much with RAID5 .. it's not easy to work with RAID5 since every slice of a RAID5 device have a little overhead that you must count in your math