Thin Provisioning Considerations when formatting volumes in a Guest OS

I had this question recently regarding the best way to format volumes in a Windows 2008 Guest OS, and if there were any considerations with the different formatting types on a volume which resides on a thin provisioned VMDK. Just to be certain that what I was stating was actually true, I set up a small test. Bottom line – use quick format when formatting the volume as a normal format will fill the volume, negating the space-saving associated with thin provisioned volumes.

Let’s begin by first of all adding a few 10GB thick volumes to this VM, a Windows 2008 Guest OS. As you can see these are ‘Thick Provisioned Lazy Zero’. 1. LZT-1And as expected, when we look via the ESXi host at how much space is consumed on the VMFS volume on which the VMDK resides, we can see that there is indeed 10GB of space consumed by the flat files for these disks. This is before we do anything in the Guest OS.

2. LZT-2OK. So now I will add 2 additional 15GB thin disks to the VM.3. TPx2And now when I examine the actual space consumed on the VMFS, I see that these flat files are not consuming any space as yet.4. TPX2 0 usedNext, let’s do some tasks in the Guest OS to make these disks useful. Initially, all 4 disks (both the thick and thin) are offline and are unallocated. The 10GB ones are the thick disks, the 15GB ones are the thin disks.5. offline disks My first step is to bring the volumes online/initialize them. I am only doing this on the thin disks. 7. Initialize DisksAfter the disks have been initialized (not formatted), I can now see that they have begun to consume some space on the VMFS volume. Since VMFS-5 blocks are allocated in 1MB chunks, one block is needed for initialization.8. Online+Initialized Space Usage Now we are ready to actually format the drive. In this first test, I am going to use the ‘Quick Format’ option to initialize the volume. A quick format is the default, and it is selected automatically. This is basically clearing the table of contents on the drive, and not touching any of the data blocks.

9. Quick Format Once the quick format has completed, I return to my ESXi host, and see how much space has been consumed.

10. Quick Format - Space UsageOK. It would appear that only 91MB of the drive that was formatted using the quick format option have been consumed by that operation. So our thin provisioned datastore is still providing some value here. Let’s now proceed with formatting my other 15GB volume using a full format option (i.e. uncheck the quick format option)

11. Format - not quickThe first thing you will notice is that the formatting takes a lot longer, and is a gradual process. The difference here is that the data blocks are also being zeroed out. 12. FormattingWhen this format is complete, I check the amount of space consumed on the VMFS volume once again. Now you can see that the whole of my thin provisioned VMDK is consuming its full amount of allocated space, negating its thin provisioning properties.

13. TP-NoQF Space UsageThis is the reason why VMware recommends using Quick Format when prepping drives in a Windows Guest OS if you wish to leverage the thin provisioned features of the VMDK. This is also highlighted in KB article 1005418.

5 Replies to “Thin Provisioning Considerations when formatting volumes in a Guest OS”

  1. Excellent information, Cormac. Thanks for this article.

    Usually, I tend to format THINLY provisioned LUN on the guest OS with QUICK format and the reason being, it is a default option [already selected] and 9/10 times I just go through the prompts and finish formatting. In such cases if you look at the LUN size at Backend storage, it shows only few KBs/Mbs [metadata], and you tend to believe you achieved what you wanted.

    But, after reading this article, I created a THIN LUN, just as I normally do on the backend [2GB/iSCSI] mapped to guest WIN2008R2 OS and formatted with ‘FULL Format’ and this time LUN usage showed full 2GB occupied, basically all my thinly properties were gone.

    And, then suddenly I realized what if I run ‘Block reclaimer’. I ran the block reclaimer using snapdrive API, and that made the LUN thin again. So, basically, if you have done FULL Format of the disk under GUEST OS, you can run ‘block reclaimer’ and still make it appear as THIN again.


  2. Thanks for sharing~~
    I also have questions if we compare with 2 options:
    1. using thin-provisioning and full format option in windows Guest OS
    2. using thick-provisioning lazy and quick format option in windows Guest OS

    Which one has better performance ?

    Similar comparison with 2 options :
    1. using thick-provisioning lazy and full format option in windows Guest OS
    2. using thick-provisioning eager and quick format option in windows Guest OS

    Which one has better performance ?

    Thanks in advance

    1. I think there is a whitepaper (from a few years back) which stated that LZT and thin were quite similar in performance.
      With EZT, all blocks are zeroed out at creation time, so creation time is longer than thin or LZT.
      With LZT, blocks are zeroed out on first access, but creation time is quick.
      Once an application deployed on LZT reaches steady-state, the performance will be the same.

Comments are closed.