Start a Conversation

This post is more than 5 years old

Solved!

Go to Solution

1158

November 20th, 2013 08:00

TDEV with 3200% total written tracks

I have two TDEV that suddenly alerted in Unisphere as 100% full.  Upon investigating I found they are showing more tracks written that we have allocated to the TDEV.  They are both over 3200% written (see below).  Each of the volumes actually has several hundred GB free.  How did this happen?  How can we fix it?  Is there a risk of continuing to use these TDEVs?  They are ESX datastores, should be migrate off of them?  Any feedback is appreciated.

C:\>symcfg list -tdev -dev 130B -detail

Symmetrix ID: XXXXXXXXXXXXX

Enabled Capacity (Tracks) : 9466672608

Bound   Capacity (Tracks) :   65536320

                     S Y M M E T R I X   T H I N   D E V I C E S

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

                                    Pool         Pool           Total      Compressed

       Bound      Flags      Total  Subs      Allocated        Written     Size/Ratio

Sym  Pool Name    ESPT      Tracks   (%)     Tracks (%)     Tracks (%)     Tracks (%)

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

130B SATA_2TB_7K  F..B    65536320     1      54576   0 2142826472 3270      54576   0

     EFD_100GB    -.--           -     -       3336   0          -   -       3336   0

     FC_600GB_15K -.--           -     -     524352   1          -   -     524352   0

Total                   ---------- ----- ---------- --- ---------- --- ---------- ---

Tracks                    65536320     1     582264   0 2142826472  23     582264   0

Legend:

Flags:  (E)mulation : A = AS400, F = FBA, 8 = CKD3380, 9 = CKD3390

         (S)hared Tracks : S = Shared Tracks Present, . = No Shared Tracks

         (P)ersistent Allocs : A = All, S = Some, . = None

         S(T)atus    : B = Bound, I = Binding, U = Unbinding, A = Allocating,

                       D = Deallocating, R = Reclaiming, C = Compressing,

                       N = Uncompressing, . = Unbound,

419 Posts

December 3rd, 2013 23:00

you-want_how_many_tb, do you have the SR number for this case, I am tracking this with an engineering OPT, I have seen this issue twice already, I can add your details.  PM me @ paule.martin @ emc.com

467 Posts

November 20th, 2013 18:00

What version of symcli are you using?

November 21st, 2013 08:00

We are using V7.5.0.7 (edit level 1604).

467 Posts

November 21st, 2013 19:00

Hrm.. I was thinking it might be a bug with symcli... But I'm not seeing anything.  I'd engage support and let us know what they have to say..

December 2nd, 2013 11:00

I did open a support case with EMC on this issue.  They were able to fix the problem, however, the only explanation I was given was that it was "a new issue we are seeing".  I don't know what was done to correct the issue, if it will come back again, or if the data in the TDEV is at risk while it is in this state.

Anyone able to provide more details?

December 11th, 2013 05:00

In working with EMC Support I have learned a few things related to this issue:

  • This is a known issue that EMC has seen but they are still not sure the condition that trigger it; currently they believe it may be related to FAST VP movement, clone operations, reclaim operation, etc.
  • The problem appears to only affect code level 5876.229.145 or above
  • There is no risk to the data when this happens, it is just a counter mismatch
  • The workaround to correct this is simple but can only be performed by a support tech so you need to open a SR with EMC - on the plus side, that will help them identify the problem so they can provide a fix.

My main concern was to know if there was a risk to the data.  Knowing there is not reduces this problem a minor annoyance in my opinion.  Thanks to everyone at EMC that followed up on this issue.

No Events found!

Top