All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
To: qemu-block@nongnu.org
Cc: fam@euphon.net, kwolf@redhat.com, vsementsov@virtuozzo.com,
	stefanha@redhat.com, codyprime@gmail.com, sw@weilnetz.de,
	pl@kamp.de, qemu-devel@nongnu.org, mreitz@redhat.com,
	ronniesahlberg@gmail.com, den@openvz.org, pbonzini@redhat.com
Subject: [PATCH v2 3/9] block/vdi: return ZERO block-status when appropriate
Date: Thu,  7 May 2020 11:47:54 +0300	[thread overview]
Message-ID: <20200507084800.20596-4-vsementsov@virtuozzo.com> (raw)
In-Reply-To: <20200507084800.20596-1-vsementsov@virtuozzo.com>

In case of !VDI_IS_ALLOCATED[], 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 at this patch and
vpc with the following) 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>
---
 block/vdi.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/block/vdi.c b/block/vdi.c
index 0c7835ae70..83471528d2 100644
--- a/block/vdi.c
+++ b/block/vdi.c
@@ -334,7 +334,6 @@ static int vdi_get_info(BlockDriverState *bs, BlockDriverInfo *bdi)
     logout("\n");
     bdi->cluster_size = s->block_size;
     bdi->vm_state_offset = 0;
-    bdi->unallocated_blocks_are_zero = true;
     return 0;
 }
 
@@ -536,7 +535,7 @@ static int coroutine_fn vdi_co_block_status(BlockDriverState *bs,
     *pnum = MIN(s->block_size - index_in_block, bytes);
     result = VDI_IS_ALLOCATED(bmap_entry);
     if (!result) {
-        return 0;
+        return BDRV_BLOCK_ZERO;
     }
 
     *map = s->header.offset_data + (uint64_t)bmap_entry * s->block_size +
-- 
2.21.0



  parent reply	other threads:[~2020-05-07  8:50 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-07  8:47 [PATCH v2 0/9] drop unallocated_blocks_are_zero Vladimir Sementsov-Ogievskiy
2020-05-07  8:47 ` [PATCH v2 1/9] qemu-img: convert: don't use unallocated_blocks_are_zero Vladimir Sementsov-Ogievskiy
2020-05-07  8:47 ` [PATCH v2 2/9] block: inline bdrv_unallocated_blocks_are_zero() Vladimir Sementsov-Ogievskiy
2020-05-07 14:08   ` Eric Blake
2020-05-28  9:31     ` Vladimir Sementsov-Ogievskiy
2020-05-07  8:47 ` Vladimir Sementsov-Ogievskiy [this message]
2020-05-07 14:10   ` [PATCH v2 3/9] block/vdi: return ZERO block-status when appropriate Eric Blake
2020-05-07  8:47 ` [PATCH v2 4/9] block/vpc: " Vladimir Sementsov-Ogievskiy
2020-05-07 14:11   ` Eric Blake
2020-05-07  8:47 ` [PATCH v2 5/9] block/crypto: drop unallocated_blocks_are_zero Vladimir Sementsov-Ogievskiy
2020-05-07  8:47 ` [PATCH v2 6/9] block/iscsi: " Vladimir Sementsov-Ogievskiy
2020-05-07  8:47 ` [PATCH v2 7/9] block/file-posix: " Vladimir Sementsov-Ogievskiy
2020-05-07  8:47 ` [PATCH v2 8/9] block/vhdx: " Vladimir Sementsov-Ogievskiy
2020-05-07  8:48 ` [PATCH v2 9/9] block: " Vladimir Sementsov-Ogievskiy
2020-05-07 14:21   ` Eric Blake
2020-05-07 14:45 ` [PATCH v2 10/9] qed: Simplify backing reads Eric Blake
2020-05-07 15:22   ` Eric Blake
2020-05-07 18:22   ` Vladimir Sementsov-Ogievskiy
2020-05-19 17:40 ` [PATCH v2 0/9] drop unallocated_blocks_are_zero 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=20200507084800.20596-4-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.