[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] block: Review of .has_zero_init use
From: |
Kevin Wolf |
Subject: |
[Qemu-devel] block: Review of .has_zero_init use |
Date: |
Tue, 25 Jun 2013 13:39:11 +0200 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
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