Re: [PATCH v2] scripts/simplebench: compare write request performance

[Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>]

13.07.2020 13:26, Andrey Shinkevich wrote:
> On 13.07.2020 11:43, Vladimir Sementsov-Ogievskiy wrote:
>> 12.07.2020 19:07, Andrey Shinkevich wrote:
>>> On 11.07.2020 16:05, Vladimir Sementsov-Ogievskiy wrote:
>>>> 26.06.2020 17:31, Andrey Shinkevich wrote:
>>>>> The script 'bench_write_req.py' allows comparing performances of write
>>>>> request for two qemu-img binary files.
>>>>> An example with (qemu-img binary 1) and without (qemu-img binary 2) the
>>>>> applied patch "qcow2: skip writing zero buffers to empty COW areas"
>>>>> (git commit ID: c8bb23cbdbe32f5)
>>>>> The <unaligned> case does not involve the COW optimization.
>>>>>
>>>> Good, this proves that c8bb23cbdbe32f5 makes sense.
>>>>
>>>>> Suggested-by: Denis V. Lunev <den@openvz.org>
>>>>> Suggested-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
>>>>> Signed-off-by: Andrey Shinkevich <andrey.shinkevich@virtuozzo.com>
>>>>> ---
>>>>> v2:
>>>>>    01: Three more test cases added to the script:
>>>>>        <simple case>
>>>>>        <general case>
>>>>>        <unaligned>
>>>>>
>>>>>   scripts/simplebench/bench_write_req.py | 201 +++++++++++++++++++++++++++++++++
>>>>>   1 file changed, 201 insertions(+)
>>>>>   create mode 100755 scripts/simplebench/bench_write_req.py
>>>>>
>>>>> diff --git a/scripts/simplebench/bench_write_req.py b/scripts/simplebench/bench_write_req.py
>>>>> new file mode 100755
>>>>> index 0000000..fe92d01
>>>>> --- /dev/null
>>>>> +++ b/scripts/simplebench/bench_write_req.py
>>>>> @@ -0,0 +1,201 @@
>>>>
>>>> Next, I don't understand, are you trying to fill qcow2 image by dd directly? This is strange. Even if you don't break metadata, you don't change it, so all cluster will remain empty.
>>>>
>>>>
>>> I have tested and it works as designed.
>>>
>>
>> But how is it designed? You just filled unallocated clusters with some data. When you read from qcow2, you'll still read zeros, because L1/L2 tables are not filled. The random data will lay untouched.
>>
>>
> 
> Sounds reasonable. But why do QEMU-ING INFO shows the actual size increased after the dd command?
> 

Because actual file size changed :) img-info shows two sizes: virtual disk size (it's unchanged of course), and real size of file, which is affected by dd of course.



-- 
Best regards,
Vladimir