From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58703) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V09ZC-0007AT-GI for qemu-devel@nongnu.org; Fri, 19 Jul 2013 08:13:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V09ZB-0001wv-FU for qemu-devel@nongnu.org; Fri, 19 Jul 2013 08:13:46 -0400 Received: from mx1.redhat.com ([209.132.183.28]:44099) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V09ZB-0001wp-7r for qemu-devel@nongnu.org; Fri, 19 Jul 2013 08:13:45 -0400 Message-ID: <51E92D5B.6020600@redhat.com> Date: Fri, 19 Jul 2013 14:13:15 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1373992168-26043-1-git-send-email-pbonzini@redhat.com> <1373992168-26043-11-git-send-email-pbonzini@redhat.com> <51E8E124.3050500@kamp.de> <51E90DD3.8030600@redhat.com> <51E90F28.9050409@kamp.de> In-Reply-To: <51E90F28.9050409@kamp.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2 10/17] block: define get_block_status return value List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Lieven Cc: famz@redhat.com, qemu-devel@nongnu.org, stefanha@redhat.com Il 19/07/2013 12:04, Peter Lieven ha scritto: > On 19.07.2013 11:58, Paolo Bonzini wrote: >> Il 19/07/2013 08:48, Peter Lieven ha scritto: >>>> - return bdrv_get_block_status(bs, sector_num, nb_sectors, pnum); >>>> + int64_t ret = bdrv_get_block_status(bs, sector_num, nb_sectors, >>>> pnum); >>>> + return >>>> + (ret & BDRV_BLOCK_DATA) || >>>> + ((ret & BDRV_BLOCK_ZERO) && !bdrv_has_zero_init(bs)); >>> i do also not understand the "((ret & BDRV_BLOCK_ZERO) && >>> !bdrv_has_zero_init(bs))"; >>> if a block is unallocated and reads as zero, but the device lacks zero >>> init, it is declared as allocated with this, isn't it? >> Thinking more about it, I would say it is a bugfix. >> >> If a block is unallocated and reads as zero, but the device lacks zero >> init, the block contents have changed since the guest was created. Thus >> the guest might well be relying on the zero content of the block, and it >> should be treated as allocated. > i was told that has_zero_init sole task is to report the state > of the device right after iscsi_create(). using it for r/w in qemu > might be a misuse. Yes, and here I'm using it exactly for that task. I'm saying "treat a zero block as allocated if it wasn't zero right after _create()". >> In any case, better safe than sorry---if in doubt, the conservative >> answer is always to return 1, and callers who want more precise >> information can use bdrv_get_block_status. > > you mean for every call to the deprecated bdrv_is_allocate()? Of course I'm not advocating returning 1 for every call. But if the semantic isn't clear, I prefer to err on the safe side. Paolo