From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41044) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Whf6v-00031g-BW for qemu-devel@nongnu.org; Tue, 06 May 2014 09:08:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Whf6m-00075i-EG for qemu-devel@nongnu.org; Tue, 06 May 2014 09:08:41 -0400 Received: from mx1.redhat.com ([209.132.183.28]:17034) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Whf6m-00075W-57 for qemu-devel@nongnu.org; Tue, 06 May 2014 09:08:32 -0400 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s46D8VNP003604 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Tue, 6 May 2014 09:08:31 -0400 Date: Tue, 6 May 2014 15:08:29 +0200 From: Kevin Wolf Message-ID: <20140506130829.GD3941@noname.str.redhat.com> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5368D629.2030302@redhat.com> 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: Paolo Bonzini Cc: qemu-devel@nongnu.org, stefanha@redhat.com Am 06.05.2014 um 14:31 hat Paolo Bonzini geschrieben: > Il 06/05/2014 13:34, Kevin Wolf ha scritto: > >But the result still wouldn't be right. We have an implication that you > >can't simply reverse: > > > > If this block is unallocated and unallocated blocks read as zero, > > then this block reads as zero. > > > >You're trying to use something like "If the block reads as zero and > >unallocated blocks read as zero, it must be unallocated", which quite > >obviously doesn't work. > > This is not what the condition says in is_allocated. The right one > is (excluding the backing_hd case, which is handled with a function > like the one I sketched in the previous message): > > If the block reads as zero and not all unallocated blocks read as > zero, the sector will be read from BS rather than the backing file, > even if it is not allocated. > > 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)". 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. Kevin