I would like to second that request.
Our use-case: we are running VMs managed by OpenNebula using ceph RBD disk images. We recently provisioned a special pool for RBD images with high IOP/s performance and predictable latency requirements. For images created on this pool we found out that thick provisioning is essential for predictable performance. The latency spike that occurs on object allocation on first write is simply not acceptable. One might want to argue that on a 3TB image with 4MB object size this happens only 786432 times, but this is exactly 786432 user complaints too many.
OpenNebula itself does not provide means for thick-provisioning. However, we have a work-around for that. The real problem is image resizing. Ideally, "--thick-provision" is not an option passed to a single command, but a sticky property of the image itself. Any operation like resize and clone should maintain this property. The "sparsify" command should remove this property and a "thicken" command should add it again, ideally executing the reclaim/allocation as an asynchronous background process.
Unfortunately, it is not a sticky property and we don't really have a safe workaround for the lack of a thick-provision resize. Using dd to initialise the newly added disk space is not really a secure option because of the implied danger of overwriting already allocated space by accident.
For starters, a command executing the operation "thicken" (inverse to "sparsify") would already help a lot (ideally executable on a busy image). In the long run, making "thick" a sticky property seems the way to go.