From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44782) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WhfIj-0003ZU-4Z for qemu-devel@nongnu.org; Tue, 06 May 2014 09:20:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WhfIc-0003hr-VT for qemu-devel@nongnu.org; Tue, 06 May 2014 09:20:53 -0400 Received: from mx1.redhat.com ([209.132.183.28]:4859) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WhfIc-0003gk-GT for qemu-devel@nongnu.org; Tue, 06 May 2014 09:20:46 -0400 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s46DKjMd021168 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Tue, 6 May 2014 09:20:45 -0400 Message-ID: <5368E1AA.2080609@redhat.com> Date: Tue, 06 May 2014 15:20:42 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1378314038-15525-1-git-send-email-pbonzini@redhat.com> <1378314038-15525-13-git-send-email-pbonzini@redhat.com> <20140505143412.GE3317@noname.str.redhat.com> <5367A711.607@redhat.com> <20140506113430.GC3941@noname.str.redhat.com> <5368D629.2030302@redhat.com> <20140506130829.GD3941@noname.str.redhat.com> In-Reply-To: <20140506130829.GD3941@noname.str.redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v5 12/21] block: define get_block_status return value List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: qemu-devel@nongnu.org, stefanha@redhat.com Il 06/05/2014 15:08, Kevin Wolf ha scritto: >> This is true, because bdrv_get_block_status does not ask the backing >> file whether it is zero in the backing file. Thus, reading from the >> backing file does not guarantee to read zeroes. > > Aha, this paragraph is the key. :-) > > I assumed that bdrv_get_block_status() does ask the backing file, but > apparently it doesn't. The current meaning of BDRV_BLOCK_ZERO is > therefore not simply "sectors read as zero", but "sectors read as zero > and this is determined by bs itself (mostly, except for the backing file > size)". Exactly. > Is it a good idea to rely on this or would it be reasonable for > bdrv_get_block_status() to look at the backing file for returning ZERO > sometime in the future? I think that could be useful information in some > cases. It is reasonable, for example SCSI emulation could use it. However, it would be a different API (like bdrv_is_allocated_above). It would be very similar to get_block_status() in qemu-img.c. Paolo