qemu-block
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-block] [Qemu-devel] [PATCH 2/2] iotests: fix 109


From: Max Reitz
Subject: Re: [Qemu-block] [Qemu-devel] [PATCH 2/2] iotests: fix 109
Date: Wed, 3 Aug 2016 18:18:39 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0

On 03.08.2016 17:22, Sascha Silbe wrote:
> 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.

As far as I'm aware, it doesn't have any real semantics besides the fact
that $offset / $len is the progress of the block job; so it's the offset
"in the job", but not the offset in the source disk.

Max

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]