From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:43189)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <morita.kazutaka@gmail.com>) id 1UrT1k-0005mO-A9
	for qemu-devel@nongnu.org; Tue, 25 Jun 2013 09:11:23 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <morita.kazutaka@gmail.com>) id 1UrT1i-0004P8-RR
	for qemu-devel@nongnu.org; Tue, 25 Jun 2013 09:11:20 -0400
Received: from mail-pa0-x229.google.com ([2607:f8b0:400e:c03::229]:40181)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <morita.kazutaka@gmail.com>) id 1UrT1i-0004MY-C4
	for qemu-devel@nongnu.org; Tue, 25 Jun 2013 09:11:18 -0400
Received: by mail-pa0-f41.google.com with SMTP id bj3so12648506pad.14
	for <qemu-devel@nongnu.org>; Tue, 25 Jun 2013 06:11:17 -0700 (PDT)
Date: Tue, 25 Jun 2013 22:11:11 +0900
Message-ID: <m2hagmz66o.wl%morita.kazutaka@gmail.com>
From: MORITA Kazutaka <morita.kazutaka@gmail.com>
In-Reply-To: <20130625113911.GD3539@dhcp-200-207.str.redhat.com>
References: <20130625113911.GD3539@dhcp-200-207.str.redhat.com>
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Subject: Re: [Qemu-devel] block: Review of .has_zero_init use
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Kevin Wolf <kwolf@redhat.com>
Cc: josh.durgin@dreamhost.com, tailai.ly@taobao.com, Peter Lieven <pl@kamp.de>, qemu-devel@nongnu.org, rjones@redhat.com, stefanha@redhat.com, bharata@linux.vnet.ibm.com, morita.kazutaka@lab.ntt.co.jp

At Tue, 25 Jun 2013 13:39:11 +0200,
Kevin Wolf wrote:
> 
> Hi all,
> 
> while discussing some iscsi patches with Peter, we came to have a look
> at which block drivers implement has_zero_init() to return 0, and which
> don't (returning 1 is the default).
> 
> The meaning of this value is that if has_zero_init != 0, after
> bdrv_create() one can assume that the whole image would read back as all
> zero. For example, this is true for the traditional image files, but not
> for host_device, where the block device isn't really created during
> bdrv_create() but only checked for size.
> 
> The full list of protocol level block drivers is:
> 
> * blkdebug      - doesn't have bdrv_create
> * blkverify     - doesn't have bdrv_create
> * curl          - doesn't have bdrv_create
> * gluster       - currently has_zero_init = 1 (is this correct?)
> * iscsi         - has_zero_init = 0
> * nbd           - doesn't have bdrv_create
> * file          - has_zero_init = 1
> * host_*        - has_zero_init = 0
> * rbd           - currently has_zero_init = 1 (is this correct?)
> * sheepdog      - currently has_zero_init = 1 (is this correct?)
> * ssh           - currently has_zero_init = 1 (is this correct?)
> * vvfat         - doesn't have bdrv_create
> 
> 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?

It's safe for Sheepdog.  Sheepdog uses ftruncate or fallocate to
create data blocks and it is guaranteed that the space will be
initialized to zero.

Thanks,

Kazutaka