« VMware Partner Exchange 2010 from where I sat | Main | Want to ask an EMC vSpecialist a question? (or how to get a free ix2/ix4) »

February 19, 2010


Feed You can follow this conversation by subscribing to the comment feed for this post.


If you do a Storage VMotion to go back to a thin vmdk make sure you zero out the VMDK before you do the Storage VMotion. The OS will not zero out when a file is deleted. Only the pointer is removed and thus a SVMotion might not lead to the expected results.


Uddhav Regmi

No sound......


3PAR can also do zero-page detection and reclimation.

Chad Sakac

@Derek - I was careful to not (and in general try to avoid) claims of "uniqueness" - these tend to be very transient.

I would expect that all thin provisioning implementations will get this over time. I know that HDS also has some zero reclaim along with 3PAR.

I'm sure there are variations (perhaps material) but I'm not qualified to judge.

The point of this post was to point out that there are several ways to skin this cat (2 at the ESX host level, 1 at the array level).

Thanks for the comment!

Uddhav Regmi

No Sound, please fix that

Fred Lherault

Just for the sake of exactitude, what the 3PAR InServ (yes I work for 3PAR) does is not zero page reclamation but online zero detection as they get written by the host, in silicon.

These zeroes are simply not being written to disk so there is no bloating of the LUN in the first place (as would happen without this zero detection during a clone/svmotion on 3.5 or by using eager zeroed thick vmdks)

You dont have to do any manual space reclamation... (although you can if you deleted files and want to reclaim the capacity they occupied)

Jack MeHoffer


What about the performance gains from using eager-zero thick disks?

Page 6:

I am getting ready force the use of eager-zero disks when we upgrade to vSphere for the performance gains. We currently do not have thin provisioning enabled on our arrays but will be doing so in the near future. Will the zero byte reclaim not yield the same result?

In my environment, we delete, create, load, and reload servers often, especially in the test environment. I have timed both operations and these are the results.

Deploy Windows 2003 server:
Zeroed Thick: 5 seconds
Eager Zeroed Thick: 2 minutes 43 seconds

Load time of Windows 2003 server:
Zeroed Thick: 4 hours 40 minutes
Eager Zeroed Thick: 4 hours 19 minutes

As you can see, using eager-zeroed disks allows the server to be loaded about 17 minutes faster from start to finish.

I am not a storage guru so let me know if there are other factors I am not aware of.

Chad Sakac

@Fred - thanks for the input, and I'm sure as the early innovator around array-based thin provisioning, 3PAR has excellence and differentiation in this particular area. Of course, I would argue that this is one of many things people look for in their storage arrays. I would also argue that it's an area where the gap is closing (wouldn't say closed). I'd also note that in vSphere 4, inline zero reclaim is offset by use of zeroedthick. Nevertheless, noted - and my respects for a strong competitor.

@Jack - there is indeed a slight performance benefit of the "pre-zero" that you get with eagerzeroedthick. The reason for this is that the vmkernel writes out a zero to that block prior to the actual data IO. IMO, except for the most extreme circumstances, the upside is outweighed by the downside - and that zeroedthick (or thin) is the way to go. Furthermore, in the next vSphere release, there is a vStorage API (engineering name is "write same/zero") that "hardware offloads" all this "zeroing" activity, which will close that gap even further - **IF** you are using a VAAI (vStorage APIs for Array Integration) compliant array (current generation EMC platforms will have this support with a software update). The array can do that more efficiently than at the ESX layer as there is the ability to batch up the IO operations en masse.


I actually do create my templates as eagerzeroedthick disks, since the performance gains (http://www.vmware.com/pdf/vsp_4_thinprov_perf.pdf) are at not costs/drawbacks for us.
We don't use SAN thin provisioning or anything ``fancy'' like that.

The clone operations are still pretty fast too.

The comments to this entry are closed.

  • BlogWithIntegrity.com


  • The opinions expressed here are my personal opinions. Content published here is not read or approved in advance by Dell Technologies and does not necessarily reflect the views and opinions of Dell Technologies or any part of Dell Technologies. This is my blog, it is not an Dell Technologies blog.