TDEV with 3200% total written tracks

Jump to solution

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,

Labels (1)
0 Kudos
1 Solution

Accepted Solutions
3 Zinc

Re: TDEV with 3200% total written tracks

Jump to solution

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

View solution in original post

0 Kudos
6 Replies
3 Cadmium

Re: TDEV with 3200% total written tracks

Jump to solution

What version of symcli are you using?

0 Kudos

Re: TDEV with 3200% total written tracks

Jump to solution

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

0 Kudos
3 Cadmium

Re: TDEV with 3200% total written tracks

Jump to solution

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

0 Kudos

Re: TDEV with 3200% total written tracks

Jump to solution

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?

0 Kudos
3 Zinc

Re: TDEV with 3200% total written tracks

Jump to solution

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

View solution in original post

0 Kudos

Re: TDEV with 3200% total written tracks

Jump to solution

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.