From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40467) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UrRam-0001vr-UV for qemu-devel@nongnu.org; Tue, 25 Jun 2013 07:39:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UrRal-0002Ci-OE for qemu-devel@nongnu.org; Tue, 25 Jun 2013 07:39:24 -0400 Received: from mx1.redhat.com ([209.132.183.28]:52758) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UrRal-0002CV-Er for qemu-devel@nongnu.org; Tue, 25 Jun 2013 07:39:23 -0400 Date: Tue, 25 Jun 2013 13:39:11 +0200 From: Kevin Wolf Message-ID: <20130625113911.GD3539@dhcp-200-207.str.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Qemu-devel] block: Review of .has_zero_init use List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Kevin Wolf , josh.durgin@dreamhost.com, tailai.ly@taobao.com, Peter Lieven , rjones@redhat.com, stefanha@redhat.com, bharata@linux.vnet.ibm.com, morita.kazutaka@lab.ntt.co.jp 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