All of lore.kernel.org
 help / color / mirror / Atom feed
From: Max Reitz <mreitz@redhat.com>
To: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>,
	qemu-devel@nongnu.org, qemu-block@nongnu.org
Cc: kwolf@redhat.com, fam@euphon.net, stefanha@redhat.com, den@openvz.org
Subject: Re: [Qemu-devel] [PATCH v2 2/2] block: avoid recursive block_status call if possible
Date: Mon, 27 May 2019 17:13:30 +0200	[thread overview]
Message-ID: <4fdb0181-b9ae-25fa-c601-9f646772c0bd@redhat.com> (raw)
In-Reply-To: <20190408162617.258535-3-vsementsov@virtuozzo.com>

[-- Attachment #1: Type: text/plain, Size: 4055 bytes --]

On 08.04.19 18:26, Vladimir Sementsov-Ogievskiy wrote:
> drv_co_block_status digs bs->file for additional, more accurate search
> for hole inside region, reported as DATA by bs since 5daa74a6ebc.
> 
> This accuracy is not free: assume we have qcow2 disk. Actually, qcow2
> knows, where are holes and where is data. But every block_status
> request calls lseek additionally. Assume a big disk, full of
> data, in any iterative copying block job (or img convert) we'll call
> lseek(HOLE) on every iteration, and each of these lseeks will have to
> iterate through all metadata up to the end of file. It's obviously
> ineffective behavior. And for many scenarios we don't need this lseek
> at all.
> 
> However, lseek is needed when we have metadata-preallocated image.
> 
> So, let's detect metadata-preallocation case and don't dig qcow2's
> protocol file in other cases.
> 
> The idea is to compare allocation size in POV of filesystem with
> allocations size in POV of Qcow2 (by refcounts). If allocation in fs is
> significantly lower, consider it as metadata-preallocation case.
> 
> 102 iotest changed, as our detector can't detect shrinked file as
> metadata-preallocation, which don't seem to be wrong, as with metadata
> preallocation we always have valid file length.
> 
> Other two iotests tiny changed QMP output sequence, which should be
> exactly because skipped lseek at mirror beginning.
> 
> Suggested-by: Denis V. Lunev <den@openvz.org>
> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
> ---
>  block/qcow2.h              |  4 ++++
>  include/block/block.h      |  8 +++++++-
>  block/io.c                 |  9 ++++++++-
>  block/qcow2-refcount.c     | 32 ++++++++++++++++++++++++++++++++
>  block/qcow2.c              | 11 +++++++++++
>  tests/qemu-iotests/102     |  2 +-
>  tests/qemu-iotests/102.out |  3 ++-
>  tests/qemu-iotests/141.out |  2 +-
>  tests/qemu-iotests/144.out |  2 +-
>  9 files changed, 67 insertions(+), 6 deletions(-)

For me, this patch breaks iotests 141 (for qed) and 211 (for vdi):

> 141 1s ...        [17:11:53] [17:11:53] - output mismatch (see 141.out.bad)
> --- tests/qemu-iotests/141.out 2019-05-27 17:11:43.327664282 +0200
> +++ build/tests/qemu-iotests/141.out.bad       2019-05-27 17:11:53.949439880 +0200
> @@ -42,9 +42,9 @@
>  {"return": {}}
>  {"timestamp": {"seconds":  TIMESTAMP, "microseconds":  TIMESTAMP}, "event": "JOB_STATUS_CHANGE", "data": {"status": "created", "id": "job0"}}
>  {"timestamp": {"seconds":  TIMESTAMP, "microseconds":  TIMESTAMP}, "event": "JOB_STATUS_CHANGE", "data": {"status": "running", "id": "job0"}}
> -{"return": {}}
>  {"timestamp": {"seconds":  TIMESTAMP, "microseconds":  TIMESTAMP}, "event": "JOB_STATUS_CHANGE", "data": {"status": "ready", "id": "job0"}}
>  {"timestamp": {"seconds":  TIMESTAMP, "microseconds":  TIMESTAMP}, "event": "BLOCK_JOB_READY", "data": {"device": "job0", "len": 0, "offset": 0, "speed": 0, "type": "commit"}}
> +{"return": {}}
>  {"error": {"class": "GenericError", "desc": "Node 'drv0' is busy: block device is in use by block job: commit"}}
>  {"return": {}}
>  {"timestamp": {"seconds":  TIMESTAMP, "microseconds":  TIMESTAMP}, "event": "JOB_STATUS_CHANGE", "data": {"status": "waiting", "id": "job0"}}

and

> 211 5s ...        [17:11:54] [17:11:58] - output mismatch (see 211.out.bad)
> --- tests/qemu-iotests/211.out 2019-05-22 19:58:34.870273427 +0200
> +++ build/tests/qemu-iotests/211.out.bad       2019-05-27 17:11:58.259348827 +0200
> @@ -55,8 +55,7 @@
>  virtual size: 32 MiB (33554432 bytes)
>  cluster_size: 1048576
>  
> -[{ "start": 0, "length": 3072, "depth": 0, "zero": false, "data": true, "offset": 1024},
> -{ "start": 3072, "length": 33551360, "depth": 0, "zero": true, "data": true, "offset": 4096}]
> +[{ "start": 0, "length": 33554432, "depth": 0, "zero": false, "data": true, "offset": 1024}]
>  
>  === Invalid BlockdevRef ===

Doesn’t look too bad, but still, broken iotests are broken iotests. :/

Max


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  parent reply	other threads:[~2019-05-27 15:14 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-08 16:26 [Qemu-devel] [PATCH v2 for 4.1 0/2] avoid lseek on block_status Vladimir Sementsov-Ogievskiy
2019-04-08 16:26 ` Vladimir Sementsov-Ogievskiy
2019-04-08 16:26 ` [Qemu-devel] [PATCH v2 1/2] tests/perf: Test lseek influence on qcow2 block-status Vladimir Sementsov-Ogievskiy
2019-04-08 16:26   ` Vladimir Sementsov-Ogievskiy
2019-04-08 16:26 ` [Qemu-devel] [PATCH v2 2/2] block: avoid recursive block_status call if possible Vladimir Sementsov-Ogievskiy
2019-04-08 16:26   ` Vladimir Sementsov-Ogievskiy
2019-05-22 10:32   ` Kevin Wolf
2019-05-27 15:13   ` Max Reitz [this message]
2019-05-28  6:39     ` Vladimir Sementsov-Ogievskiy
2019-05-28 15:47       ` Max Reitz
2019-04-22  9:58 ` [Qemu-devel] [PATCH v2 for 4.1 0/2] avoid lseek on block_status Vladimir Sementsov-Ogievskiy
2019-04-22  9:58   ` Vladimir Sementsov-Ogievskiy
2019-05-06 15:14 ` Vladimir Sementsov-Ogievskiy
2019-05-21  7:50 ` [Qemu-devel] ping " Vladimir Sementsov-Ogievskiy
2019-05-22 10:47 ` [Qemu-devel] " Kevin Wolf
2019-05-22 11:30   ` 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=4fdb0181-b9ae-25fa-c601-9f646772c0bd@redhat.com \
    --to=mreitz@redhat.com \
    --cc=den@openvz.org \
    --cc=fam@euphon.net \
    --cc=kwolf@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    --cc=vsementsov@virtuozzo.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 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.