[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-block] [Qemu-devel] [PATCH 2/2] iotests: fix 109
From: |
Sascha Silbe |
Subject: |
Re: [Qemu-block] [Qemu-devel] [PATCH 2/2] iotests: fix 109 |
Date: |
Wed, 03 Aug 2016 17:22:22 +0200 |
User-agent: |
Notmuch/0.22.1~rc0 (http://notmuchmail.org) Emacs/24.3.1 (x86_64-pc-linux-gnu) |
Dear Vladimir,
Vladimir Sementsov-Ogievskiy <address@hidden> writes:
> 109 iotest is broken for raw after 0965a41e998ab820b5
> [mirror: double performance of the bulk stage if the disc is full]
>
> The problem is with finishing block-job with error: before specified
> patch mirror was not very async and it created one big request at disk
> start, this request finished with error and qemu produced
> BLOCK_JOB_COMPLETED with zero progress.
>
> After 0965a41, mirror starts several smaller requests in parallel, when
> BLOCK_JOB_COMPLETED emited we have some successful non-zero progress.
[...]
> --- a/tests/qemu-iotests/109.out
> +++ b/tests/qemu-iotests/109.out
> @@ -135,7 +135,7 @@ Automatically detecting the format is dangerous for raw
> images, write operations
> Specify the 'raw' format explicitly to remove the restrictions.
> {"return": {}}
> {"timestamp": {"seconds": TIMESTAMP, "microseconds": TIMESTAMP}, "event":
> "BLOCK_JOB_ERROR", "data": {"device": "src", "operation": "write", "action":
> "report"}}
> -{"timestamp": {"seconds": TIMESTAMP, "microseconds": TIMESTAMP}, "event":
> "BLOCK_JOB_COMPLETED", "data": {"device": "src", "len": 2560, "offset": 0,
> "speed": 0, "type": "mirror", "error": "Operation not permitted"}}
> +{"timestamp": {"seconds": TIMESTAMP, "microseconds": TIMESTAMP}, "event":
> "BLOCK_JOB_COMPLETED", "data": {"device": "src", "len": 2560, "offset":
> OFFSET, "speed": 0, "type": "mirror", "error": "Operation not permitted"}}
What are the exact semantics of the "offset" field for
BLOCK_JOB_COMPLETED?
docs/qmp-events.txt is rather vague. As an API consumer I'd have assumed
that everything up to offset has been completed successfully. If that
interpretation is correct, offset must be 0 for this test because the
very first sector wasn't mirrored successfully.
Sascha
--
Softwareentwicklung Sascha Silbe, Niederhofenstraße 5/1, 71229 Leonberg
https://se-silbe.de/
USt-IdNr. DE281696641