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