So the other day, a bunch of us were asked the question:
“A customer of ours has asked if the partial writes issue with linked clones that was found in View and fixed in 5.2 with SE sparse disks has also been fixed in vCloud Director Fast Provisioning with SE sparse disks”
This is possibly the most exciting new storage feature in the vSphere 5.1 release. Space Efficient Sparse Virtual Disks (or SE Sparse Disks for short) were designed to alleviate two issues. Let’s describe these issues first of all.
Problem Statement #1 – Let’s take a Guest OS running on a linked clone (View desktop if you will), and this Guest OS issues a 4KB write. vmfsSparse disk (which is the format used by traditional linked clones) has a block allocation unit size of 512 bytes. In other words, this Guest OS is backed by 512 byte blocks. Depending on the applications deployed in the Guest OS, a worst case scenario is that these 512 byte blocks may not be contiguous on the VMDK, and thus may not be contiguous on the VMFS or NFS datastore. This could lead to multiple writes taking place on the back-end storage array for a single Guest OS write. Another side effect is that the partition created on Guest OS may also be misaligned (because of the very small allocation unit size), again causing multiple writes to take place on the array for a single Guest OS write. Finally, this 512 byte block allocation unit size may not match the block size preference of the storage array, leading to additional overhead in handling these smaller, partial writes.
The answer we have got back from Engineering teams regarding this question:
vCloud Director does not leverage seSparse disks though View does (so far, the characteristics of SESparse are better suited to that use case). vCloud Director can however leverage array offloaded clones (when supported by NAS arrays through VAAI) to mitigate misalignment issues.
Now in my opinion it would be really great if vCloud Director leveraged SE Sparse disks, I think it is a very valid use case, however I guess that is for another day.
Big thanks goes to Michael Haines for using his seemingly unlimited connections in Engineering.