Re: [Qemu-devel] block: Review of .has_zero_init use

[Bharata B Rao <bharata@linux.vnet.ibm.com>]

On Wed, Jun 26, 2013 at 07:59:27AM +0200, Peter Lieven wrote:
> 
> Am 26.06.2013 um 05:14 schrieb Bharata B Rao <bharata@linux.vnet.ibm.com>:
> 
> > On Tue, Jun 25, 2013 at 01:39:11PM +0200, Kevin Wolf wrote:
> >> 
> >> Can you please review for the gluster, rbd, sheepdog and ssh driver
> >> whether it's safe to assume that the image reads back as zeros after
> >> bdrv_create?
> > 
> > Gluster supports both file and block backends. While the above is true for
> > file backend (which uses ftruncate), the same is not true for
> > block backend (which uses lvcreate & lvresize).
> > 
> > So overall it is not safe to assume that an image on GlusterFS volume
> > reads back as zeroes after create.
> 
> Okay, so for safety we have to return has_zero_init = 0. Erroneously assuming
> a device is zero initialized can bring severe filesystem corruption.
> 
> Do you see a way to query the information of the underlaying
> backend from the storage and return 1 or 0 conditionally?

Right now no. There have been efforts to get the capabilities (file, block etc)
of gluster volume from gluster cmdline, but there haven't been discussions
about providing such capabilities from libgfapi which is the library
QEMU uses to talk with gluster.

I see has_zero_init being used from qemu-img convert path. Is there any
other use of this in QEMU ?

Regards,
Bharata.