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 <bhar...@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 ?
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
