From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53223) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UrTZu-0005XI-1D for qemu-devel@nongnu.org; Tue, 25 Jun 2013 09:46:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UrTZp-0000dx-AU for qemu-devel@nongnu.org; Tue, 25 Jun 2013 09:46:37 -0400 Received: from mx1.redhat.com ([209.132.183.28]:39703) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UrTZo-0000dl-WA for qemu-devel@nongnu.org; Tue, 25 Jun 2013 09:46:33 -0400 Date: Tue, 25 Jun 2013 15:45:51 +0200 From: Kevin Wolf Message-ID: <20130625134551.GM3539@dhcp-200-207.str.redhat.com> References: <20130625113911.GD3539@dhcp-200-207.str.redhat.com> <20130625132018.GK3539@dhcp-200-207.str.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] block: Review of .has_zero_init use List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: MORITA Kazutaka Cc: josh.durgin@dreamhost.com, tailai.ly@taobao.com, Peter Lieven , qemu-devel@nongnu.org, rjones@redhat.com, stefanha@redhat.com, bharata@linux.vnet.ibm.com, morita.kazutaka@lab.ntt.co.jp Am 25.06.2013 um 15:42 hat MORITA Kazutaka geschrieben: > At Tue, 25 Jun 2013 15:20:18 +0200, > Kevin Wolf wrote: > > > > Am 25.06.2013 um 15:11 hat MORITA Kazutaka geschrieben: > > > 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. > > > > Note that ftruncate/fallocate don't zero-initialise block devices, only > > regular files. Not sure if you can use block devices to back Sheepdog > > images? > > We cannot do that. Sheepdog heavily relies on filesystem features and > we will not support block devices for the backend of Sheepdog. Okay, so Sheepdog is indeed safe. Thanks, Kazutaka! Kevin