[Top][All Lists]

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

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

From: Vladimir Sementsov-Ogievskiy
Subject: Re: [PATCH v2] scripts/simplebench: compare write request performance
Date: Mon, 13 Jul 2020 15:36:50 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0

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>
   01: Three more test cases added to the script:
       <simple case>
       <general case>

  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 
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 

Best regards,

reply via email to

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