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

[Kevin Wolf <kwolf@redhat.com>]

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 might be possible that the correct value depends on the backend on
the server side for some protocols - for example, I think for SSH it
depends on whether you access a regular file or a block device on the
other host (if accessing a block device is even possible). In such
cases, has_zero_init = 0 is the safe default.

We're probably going to change the meaning of unimplemented
has_zero_init to return 0, but it would be good to check if the current
code was actually meant to do what it does today.

Kevin