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

[Andrey Shinkevich]

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?

Andrey


> > This dd command doesn't hurt the metadata and fills the image with 
> > random data. The actual disk size becomes about 1G after the dd command.