codyhosterman
3 Argentium

Re: How will ESX handle Virtual Provisioned LUN

Jump to solution

Great, glad i could help!

0 Kudos
jingyi1
3 Argentium

Re: How will ESX handle Virtual Provisioned LUN

Jump to solution

Victor, I'm using SE version 7.3.2.2.  I actually did the operation on SMC instead of CLI. Below is the SMC reclaim screenshot.

Capture.PNG

After creating 8G eager zero thick device, Used CLI to display allocated and written tracks.

                       Pool          Pool             Total                 

   Sym          Total  Subs        Allocated         Written             

   Dev         Tracks   (%)     Tracks   (%)     Tracks   (%)  Status 

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

   0756        982800    11     142008    14       9834     1  Bound     

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

   Tracks      982800    11     142008    14       9834     1

  }

Allocated tracks rise from 10920 to 142008.

Then I used SMC to start Reclaim, uncheck the persistent option.

                      Pool          Pool             Total                 

   Sym          Total  Subs        Allocated         Written             

   Dev         Tracks   (%)     Tracks   (%)     Tracks   (%)  Status 

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

   0756        982800    11     141720    14       9518     1  Reclaiming

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

   Tracks      982800    11     141720    14       9518     1

  }

There were very few tracks being de-allocated.

Selectd Start Free, still uncheck the persistent option.

                       Pool          Pool             Total                 

   Sym          Total  Subs        Allocated         Written             

   Dev         Tracks   (%)     Tracks   (%)     Tracks   (%)  Status 

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

   0756        982800    11      10608     1       9517     1  Bound     

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

   Tracks      982800    11      10608     1       9517     1

  }

You can see almost all 8G were de-allocated.

Cody, now you can see why I ask the difference between Start Reclaim and Start Free. I still don't undetstand the logic behind these 2 options.

0 Kudos
codyhosterman
3 Argentium

Re: How will ESX handle Virtual Provisioned LUN

Jump to solution

If you are deploying an eagerzeroedthick virtual disk with ESX 4.1+ and Enginuity 5875 the ESX host will use write same and not actually write the zeros. It will only set the tracks Not Written By Host and then allocate the given extents (each extent =12 tracks=768KB). This is why there is no real difference in the written tracks after deployment. The written tracks that exist are simply just the VMFS metadata. Since no zeroes are written, there is no real difference in the way free or reclaim behave (or shouldn’t be). Free only de-allocates extents that are NWBH and since that is what the EZT deployment did, all of those tracks should be free after the start free. Start reclaim should query all of the allocated extents for extents that are filled with contiguous zeros or fully NWBH. Extents that are fully NWBH will be de-allocated and all-zero extents will be marked NWBH and then de-allocated.

The second pool show you have still shows the device as reclaiming. What was its final state?

jingyi1
3 Argentium

Re: How will ESX handle Virtual Provisioned LUN

Jump to solution

Cody, thanks for your quick response. You are right about this, Free only de-allocates extents that are NWBH and  reclaim de-allocated extents that are filled with contiguous zeros or fully NWBH. The second pool show is still reclaiming, I must have captured the screen too early. So I redid the test and found reclaiming acted  exactly same as you said.

I also have another interesting finding. For all-zero tracks, reclaiming, will reduce total written tracks  by 316 tracks while reduce all allocated only by 288 tracks.

Did the free operation first,

Pool Bound Thin Devices(1):

  {

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

                       Pool          Pool             Total                 

   Sym          Total  Subs        Allocated         Written             

   Dev         Tracks   (%)     Tracks   (%)     Tracks   (%)  Status 

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

   0756        982800    11      11892     1       9919     1  Bound     

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

   Tracks      982800    11      11892     1       9919     1

  }

Start  reclaim

Pool Bound Thin Devices(1):

  {

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

                       Pool          Pool             Total                 

   Sym          Total  Subs        Allocated         Written             

   Dev         Tracks   (%)     Tracks   (%)     Tracks   (%)  Status 

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

   0756        982800    11      11604     1       9603     1  Bound     

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

   Tracks      982800    11      11604     1       9603     1

11892-11604=288

9919-9603-316

316-288=28 tracks

I tested twice and got same result. My thin meta device has 10 meta memebers. I don't know if the difference has something to do with Data structure, or it's the designed behavior for thin device allocate and reclaim.

Cody, I also read this primus emc277013, it mentioned:

When space is allocated the Symmetrix Enginuity code will fill the space with zeros. As the allocated space is used up it is overwrites the initial zeros. Therefore simply deleting the files from the allocated space does not meet the criteria for reclaiming space. The customer would have to fill the entire allocated space that was used with zeros, then they should be able to perform the reclaim. EMC has no procedure on how to fill a disk with zeros. The customer would have to write a script of his own.

As current Enginuity does not support UNMAP command, is there any setting or tool in vmware to write zeros to the dead space which was written by non-zero value before? If yes, these space then can be reclaimed later manually. I am also curious about the implementation of UNMAP command if it become supported later. Will the tracks de-allocated be written to all zeros before retuning to pool? or these tracks will be designed to zero out only on allocation phase?

0 Kudos
codyhosterman
3 Argentium

Re: How will ESX handle Virtual Provisioned LUN

Jump to solution

I actually just updated the virtual provisioning with vSphere white paper this week to include a way to reclaim dead space by zeroing it in VMware and then reclaiming it. Check it out here:

http://www.emc.com/collateral/hardware/white-papers/h6813-implting-symmetrix-vrtl-prvsning-vsphere-w...

There is a section called reclaiming space on symmetrix thin devices and goes through the process.

UNMAP just sets the tracks NWBH and then de-allocates the extents as well. There is no zeroing involved. The write same with the UNMAP bit set will do this though--but this is not used often. The only thing that uses write same with the UNMAP bit set is the storreclaim utility that we offer through PSE.

I believe the difference you are seeing is that metamember require that a certain amount of allocation to remain even if they have no data (the act of binding does this). These extents cannot be reclaimed fully, just set NWBH.

jingyi1
3 Argentium

Re: How will ESX handle Virtual Provisioned LUN

Jump to solution

Cody, you are amazing to answer all questions I might think of. Just downloaded the updated WP, it seems not be published in powerlink officially. I am eager to see UNMAP being supported by later enginuity, probably 5876?  Look forward to discussing with you later.

0 Kudos
Highlighted
codyhosterman
3 Argentium

Re: How will ESX handle Virtual Provisioned LUN

Jump to solution

Happy to help! Yeah Powerlink takes a little bit longer to post than EMC.com.

0 Kudos