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

[Kevin Wolf]

Am 26.06.2013 um 08:46 hat Bharata B Rao geschrieben:
> On Wed, Jun 26, 2013 at 07:59:27AM +0200, Peter Lieven wrote:
> > 
> > Am 26.06.2013 um 05:14 schrieb Bharata B Rao <address@hidden>:
> > 
> > > 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 ?

No, it's the only user.

So what this means is that using 'qemu-img convert' with a glusterfs
target corrupts the image if the volume is backed by a block device.

Kevin