qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Kevin Wolf <kwolf@redhat.com>
Cc: qemu-devel@nongnu.org, stefanha@redhat.com
Subject: Re: [Qemu-devel] [PATCH v5 12/21] block: define get_block_status return value
Date: Tue, 06 May 2014 14:31:37 +0200	[thread overview]
Message-ID: <5368D629.2030302@redhat.com> (raw)
In-Reply-To: <20140506113430.GC3941@noname.str.redhat.com>

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.

<pedantic>
Since you wrote "something like", I guess it's not the difference 
between what you wrote and what I wrote is not too relevant.  But here 
is the pedantic explanation of it:

- is_allocated does not answer the question "is the block allocated", 
but rather "will the sector be read from BS or from a backing file?" (or 
from an imaginary all-zeroes backing file if there is none).  This is 
why it is better to rename is_allocated before it brings more confusion 
(and the brain damage I got from this confusion is also the reason why 
BDRV_BLOCK_DATA is not called BDRV_BLOCK_ALLOCATED).

- this is the right hand side of a "||", so the outcome is not "it must 
be unallocated", but "it must be allocated".  Or better, given the 
previous point, "the sector will be read from BS"

- the bdrv_has_zero_init (which is wrong, but can be fixed) is negated, 
so it is not "unallocated blocks are zero" but rather "if the block 
reads as zero and not all unallocated blocks read as zero".
</pedantic>

Paolo

  reply	other threads:[~2014-05-06 12:31 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-04 17:00 [Qemu-devel] [PATCH v5 00/21] Add qemu-img subcommand to dump file metadata Paolo Bonzini
2013-09-04 17:00 ` [Qemu-devel] [PATCH v5 01/21] cow: make reads go at a decent speed Paolo Bonzini
2013-09-04 17:00 ` [Qemu-devel] [PATCH v5 02/21] cow: make writes go at a less indecent speed Paolo Bonzini
2013-09-04 17:00 ` [Qemu-devel] [PATCH v5 03/21] cow: do not call bdrv_co_is_allocated Paolo Bonzini
2013-09-04 17:00 ` [Qemu-devel] [PATCH v5 04/21] block: keep bs->total_sectors up to date even for growable block devices Paolo Bonzini
2013-09-04 17:00 ` [Qemu-devel] [PATCH v5 05/21] block: make bdrv_co_is_allocated static Paolo Bonzini
2013-09-04 17:00 ` [Qemu-devel] [PATCH v5 06/21] block: do not use ->total_sectors in bdrv_co_is_allocated Paolo Bonzini
2013-09-04 17:00 ` [Qemu-devel] [PATCH v5 07/21] block: remove bdrv_is_allocated_above/bdrv_co_is_allocated_above distinction Paolo Bonzini
2013-09-04 17:00 ` [Qemu-devel] [PATCH v5 08/21] block: expect errors from bdrv_co_is_allocated Paolo Bonzini
2013-09-04 17:00 ` [Qemu-devel] [PATCH v5 09/21] qemu-img: always probe the input image for allocated sectors Paolo Bonzini
2013-09-04 17:00 ` [Qemu-devel] [PATCH v5 10/21] block: make bdrv_has_zero_init return false for copy-on-write-images Paolo Bonzini
2013-09-04 17:00 ` [Qemu-devel] [PATCH v5 11/21] block: introduce bdrv_get_block_status API Paolo Bonzini
2013-09-04 17:00 ` [Qemu-devel] [PATCH v5 12/21] block: define get_block_status return value Paolo Bonzini
2014-05-05 14:34   ` Kevin Wolf
2014-05-05 14:58     ` Paolo Bonzini
2014-05-06 11:34       ` Kevin Wolf
2014-05-06 12:31         ` Paolo Bonzini [this message]
2014-05-06 13:08           ` Kevin Wolf
2014-05-06 13:20             ` Paolo Bonzini
2013-09-04 17:00 ` [Qemu-devel] [PATCH v5 13/21] block: return get_block_status data and flags for formats Paolo Bonzini
2013-09-04 17:00 ` [Qemu-devel] [PATCH v5 14/21] block: use bdrv_has_zero_init to return BDRV_BLOCK_ZERO Paolo Bonzini
2013-09-04 17:00 ` [Qemu-devel] [PATCH v5 15/21] block: return BDRV_BLOCK_ZERO past end of backing file Paolo Bonzini
2013-09-04 17:00 ` [Qemu-devel] [PATCH v5 16/21] qemu-img: add a "map" subcommand Paolo Bonzini
2013-09-04 17:00 ` [Qemu-devel] [PATCH v5 17/21] docs, qapi: document qemu-img map Paolo Bonzini
2013-09-04 17:00 ` [Qemu-devel] [PATCH v5 18/21] raw-posix: return get_block_status data and flags Paolo Bonzini
2013-09-04 17:00 ` [Qemu-devel] [PATCH v5 19/21] raw-posix: report unwritten extents as zero Paolo Bonzini
2013-09-04 17:00 ` [Qemu-devel] [PATCH v5 20/21] block: add default get_block_status implementation for protocols Paolo Bonzini
2013-09-04 17:00 ` [Qemu-devel] [PATCH v5 21/21] block: look for zero blocks in bs->file Paolo Bonzini
2013-09-05 13:55 ` [Qemu-devel] [PATCH v5 00/21] Add qemu-img subcommand to dump file metadata Stefan Hajnoczi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5368D629.2030302@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).