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

[MORITA Kazutaka <morita.kazutaka@gmail.com>]

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