All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
To: qemu-block@nongnu.org
Cc: kwolf@redhat.com, fam@euphon.net, vsementsov@virtuozzo.com,
	ronniesahlberg@gmail.com, codyprime@gmail.com, sw@weilnetz.de,
	pl@kamp.de, qemu-devel@nongnu.org, mreitz@redhat.com,
	stefanha@redhat.com, pbonzini@redhat.com, den@openvz.org
Subject: [PATCH v3 04/10] block/vpc: return ZERO block-status when appropriate
Date: Thu, 28 May 2020 12:43:59 +0300	[thread overview]
Message-ID: <20200528094405.145708-5-vsementsov@virtuozzo.com> (raw)
In-Reply-To: <20200528094405.145708-1-vsementsov@virtuozzo.com>

In case when get_image_offset() returns -1, we do zero out the
corresponding chunk of qiov. So, this should be reported as ZERO.

Note that this changes visible output of "qemu-img map --output=json"
and "qemu-io -c map" commands. For qemu-img map, the change is obvious:
we just mark as zero what is really zero. For qemu-io it's less
obvious: what was unallocated now is allocated.

There is an inconsistency in understanding of unallocated regions in
Qemu: backing-supporting format-drivers return 0 block-status to report
go-to-backing logic for this area. Some protocol-drivers (iscsi) return
0 to report fs-unallocated-non-zero status (i.e., don't occupy space on
disk, read result is undefined).

BDRV_BLOCK_ALLOCATED is defined as something more close to
go-to-backing logic. Still it is calculated as ZERO | DATA, so 0 from
iscsi is treated as unallocated. It doesn't influence backing-chain
behavior, as iscsi can't have backing file. But it does influence
"qemu-io -c map".

We should solve this inconsistency at some future point. Now, let's
just make backing-not-supporting format drivers (vdi in the previous
patch and vpc now) to behave more like backing-supporting drivers
and not report 0 block-status. More over, returning ZERO status is
absolutely valid thing, and again, corresponds to how the other
format-drivers (backing-supporting) work.

After block-status update, it never reports 0, so setting
unallocated_blocks_are_zero doesn't make sense (as the only user of it
is bdrv_co_block_status and it checks unallocated_blocks_are_zero only
for unallocated areas). Drop it.

Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
---
 block/vpc.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/block/vpc.c b/block/vpc.c
index c055591641..01fcd37e3c 100644
--- a/block/vpc.c
+++ b/block/vpc.c
@@ -606,7 +606,6 @@ static int vpc_get_info(BlockDriverState *bs, BlockDriverInfo *bdi)
         bdi->cluster_size = s->block_size;
     }
 
-    bdi->unallocated_blocks_are_zero = true;
     return 0;
 }
 
@@ -745,7 +744,7 @@ static int coroutine_fn vpc_co_block_status(BlockDriverState *bs,
     image_offset = get_image_offset(bs, offset, false, NULL);
     allocated = (image_offset != -1);
     *pnum = 0;
-    ret = 0;
+    ret = BDRV_BLOCK_ZERO;
 
     do {
         /* All sectors in a block are contiguous (without using the bitmap) */
-- 
2.18.0



  parent reply	other threads:[~2020-05-28  9:47 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-28  9:43 [PATCH v3 00/10] drop unallocated_blocks_are_zero Vladimir Sementsov-Ogievskiy
2020-05-28  9:43 ` [PATCH v3 01/10] qemu-img: convert: don't use unallocated_blocks_are_zero Vladimir Sementsov-Ogievskiy
2020-05-28  9:43 ` [PATCH v3 02/10] block: inline bdrv_unallocated_blocks_are_zero() Vladimir Sementsov-Ogievskiy
2020-05-28  9:43 ` [PATCH v3 03/10] block/vdi: return ZERO block-status when appropriate Vladimir Sementsov-Ogievskiy
2020-05-28  9:43 ` Vladimir Sementsov-Ogievskiy [this message]
2020-07-06  8:28   ` [PATCH v3 04/10] block/vpc: " Max Reitz
2020-07-06  9:17     ` Vladimir Sementsov-Ogievskiy
2020-05-28  9:44 ` [PATCH v3 05/10] block/crypto: drop unallocated_blocks_are_zero Vladimir Sementsov-Ogievskiy
2020-05-28  9:44 ` [PATCH v3 06/10] block/iscsi: " Vladimir Sementsov-Ogievskiy
2020-05-28  9:44 ` [PATCH v3 07/10] block/file-posix: " Vladimir Sementsov-Ogievskiy
2020-05-28  9:44 ` [PATCH v3 08/10] block/vhdx: " Vladimir Sementsov-Ogievskiy
2020-05-28  9:44 ` [PATCH v3 09/10] block: " Vladimir Sementsov-Ogievskiy
2020-05-28  9:44 ` [PATCH v3 10/10] qed: Simplify backing reads Vladimir Sementsov-Ogievskiy
2020-07-03 14:06 ` [PATCH v3 00/10] drop unallocated_blocks_are_zero Max Reitz
2020-07-03 18:08   ` Vladimir Sementsov-Ogievskiy

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=20200528094405.145708-5-vsementsov@virtuozzo.com \
    --to=vsementsov@virtuozzo.com \
    --cc=codyprime@gmail.com \
    --cc=den@openvz.org \
    --cc=fam@euphon.net \
    --cc=kwolf@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=pl@kamp.de \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=ronniesahlberg@gmail.com \
    --cc=stefanha@redhat.com \
    --cc=sw@weilnetz.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.