From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49340) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UrkHT-0001Pt-VI for qemu-devel@nongnu.org; Wed, 26 Jun 2013 03:36:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UrkHS-0003Zf-PK for qemu-devel@nongnu.org; Wed, 26 Jun 2013 03:36:43 -0400 Received: from mx1.redhat.com ([209.132.183.28]:28895) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UrkHS-0003ZX-G8 for qemu-devel@nongnu.org; Wed, 26 Jun 2013 03:36:42 -0400 Date: Wed, 26 Jun 2013 09:36:27 +0200 From: Kevin Wolf Message-ID: <20130626073627.GA2720@dhcp-200-207.str.redhat.com> References: <20130625113911.GD3539@dhcp-200-207.str.redhat.com> <20130626031447.GD9966@in.ibm.com> <33D3F375-B15B-41BE-8033-4D1A088F25A8@kamp.de> <20130626064604.GE9966@in.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130626064604.GE9966@in.ibm.com> Subject: Re: [Qemu-devel] block: Review of .has_zero_init use List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Bharata B Rao Cc: josh.durgin@dreamhost.com, tailai.ly@taobao.com, Peter Lieven , qemu-devel@nongnu.org, rjones@redhat.com, stefanha@redhat.com, morita.kazutaka@lab.ntt.co.jp 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 : > > > > > 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